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

[Jeff Roach]

On Wed, Oct 21, 2026 at 5:34 PM Jeff Roach <jeff.roach0 at gmail.com> wrote:
>
> Hi all,
>
> I have a device tree for the HP OmniBook X Laptop 16-cp1xxx (board
> 8F46, Snapdragon X2 Elite 12-core, "qcom,mahua") that boots and runs a

Hi all,

A follow-up with one new result: DisplayPort alt mode on the USB-C
ports, and what looks like a wrong clock divider in the Glymur combo
PHY driver.

Setup: mdss_dp0/mdss_dp1 enabled as in glymur-hp-elitebook-x-g2q.dts
(glymur.dtsi already links them to usb_0/usb_1_qmpphy, and
pmic_glink_altmode provides HPD). Sink: USB-C hub with a Parade PS176
DP-to-HDMI converter, 1080p monitor. The same hub and monitor work
under Windows on this laptop.

With the default link-frequencies the driver picked HBR2, 2 lanes.
AUX, EDID and link training all succeeded (drm.debug shows "mainlink
READY", 1920x1080 at 60, 148.5 MHz, sensible Mvid/Nvid), and GNOME showed
the monitor as active, but the monitor reported "No signal".

Counting vblanks with DRM_IOCTL_WAIT_VBLANK on that CRTC gave exactly
33.33 ms per frame, i.e. 30 Hz for a 60 Hz mode (the eDP CRTC measured
59.86 Hz at the same time). So the timing engine appears to run at
half the pixel clock the stream header announces, and the PS176 never
locks.

Capping link-frequencies at HBR in the DT
(<1620000000 2700000000>) fixes it: the same CRTC measures 60.000 Hz
and the monitor shows a picture. Both USB-C ports (mdss_dp0 and
mdss_dp1) behave the same way.

Looking at drivers/phy/qualcomm/phy-qcom-qmp-combo.c,
qmp_v8_configure_dp_clocks() (used by glymur_usb3dpphy_cfg) sets
phy_vco_div = 0x4 / 0x2 / 0x4 / 0x3 for RBR / HBR / HBR2 / HBR3. The
Glymur eDP PHY in phy-qcom-edp.c (edp_phy_vco_div_cfg_v8) uses 0x00 /
0x00 / 0x02 / 0x01. I haven't checked this against documentation (I
don't have any), and I haven't yet tried a patched module, so it is
only a suspicion that the HBR2 (and maybe HBR3) value is wrong. It is
the same in linux-next as far as I can see.

Questions:
- Does the HBR2 divider in qmp_v8_configure_dp_clocks() look right to
  you? If someone can tell me the expected value I'm happy to build
  the module and test HBR2 and HBR3.
- Is capping link-frequencies acceptable in a board DTS until this is
  understood, or should I leave DP out of the first submission?

Details:
https://github.com/jeffroach0/omnibook-x16-linux/blob/main/docs/findings.md#displayport-over-usb-c

Thanks,
Jeff