HP OmniBook X 16 (X2 Elite, Mahua): DT bring-up report and questions

[Jeff Roach]

On Thu, Oct 22, 2026 at 3:27 AM Konrad Dybcio
<konrad.dybcio at oss.qualcomm.com> wrote:
>
>
> Can you give this series a shot?
>
> https://lore.kernel.org/linux-arm-msm/20261001-glymur-phy-v3-v5-0-3848c2615d5a@oss.qualcomm.com/
>

Thanks, that fixes it. With the series, DP alt mode works at HBR2 on
this machine.

Setup: Ubuntu 7.3.0-21 kernel, phy-qcom-qmp-combo built out of tree
from the 7.3 source plus all 11 patches (patch 4 needed a small manual
fix for context, since this tree doesn't have the USB4 block). I
removed the link-frequencies cap from mdss_dp0_out/mdss_dp1_out, so
the full 1.62/2.7/5.4/8.1 GHz list is back. Sink is an Anker USB-C
hub (Parade PS176 DP-to-HDMI) into a 1080p monitor, on the usb_0 port.
The hub runs DP on 2 lanes and USB3 on the other 2.

- Picture is sharp and stable (before the series: "No signal" at HBR2).
- DPCD 0x100/0x101 = 14 82 (HBR2, 2 lanes, enhanced framing).
- DPCD 0x202-0x204 = 77 00 81 (lanes 0/1 CR + EQ + symbol lock,
  interlane aligned).
- Measured vblank rate on that CRTC: 60.000 Hz for 1920x1080 at 60.
  Before the series, at HBR2, the same mode ran at exactly 30 Hz.
- Works in both plug orientations.
- Plain USB3 on the patched PHY is fine: a USB 3.2 Gen1 stick
  directly in the other USB-C port enumerates at 5000M and works.

Tested-by: Jeff Roach <jeff.roach0 at gmail.com> # HP OmniBook X 16 (Mahua)

Two intermittent things I saw over four plug-ins of the hub, in case
they are useful. I can't tell yet whether they are the PHY, the hub,
or the cable:

1. One of the four plug-ins gave no picture. DPCD 0x100/0x101 was
   still 14 82, but 0x202-0x204 = 00 00 80 (no clock recovery on
   either lane), and dpu logged "vblank timeout", "wait for commit
   done returned -110" and "frame done timeout". Replugging fixed it.
   I first thought it was orientation-dependent, but the same
   orientation worked on a later plug-in.

2. On three of the four plug-ins, the hub's USB3 side kept dropping
   and re-enumerating every few seconds while DP was running ("can't
   restore configuration #1 (error=-110)", "set hub depth failed",
   "device not accepting address, error -71"). Unplugging only the
   HDMI cable from the hub stopped it within a minute. On the other
   plug-in, USB3 stayed stable at 5000M with DP running. The hub also
   logs a "URB submitted while active" warning in hub_activate() even
   without DP, so part of this may be the hub itself.

I can collect drm.debug logs or test patches if either of these
looks worth chasing.

Thanks,
Jeff