phy-qcom-qmp-combo: com_aux enable fails on a DP-only instance with no USB half (Snapdragon X2 Elite / glymur)

phy-qcom-qmp-combo: com_aux enable fails on a DP-only instance with no USB half (Snapdragon X2 Elite / glymur)

[Jesse Casco]

Hi,

On the ASUS Zenbook A16 (UX3607OA, Snapdragon X2 Elite Extreme, glymur /
X2E94100) the internal HDMI output never produces a picture, and a second
problem turns that into an unusable machine. I would like verification on
the reading of both.

The failure

	Failed to enable clk 'com_aux': -16
	phy phy-88e1000.phy.7: phy init failed --> -16
	  clk_branch_toggle <- clk_branch2_enable <- qmp_combo_com_init
	    <- qmp_combo_dp_init <- phy_init

Plugging a display in afterwards produces only "phy_power_on was called
before phy_init", and the connector comes up with nothing behind it:

	                      status         EDID      modes
	nothing attached      disconnected   0 bytes   0
	display attached      connected      0 bytes   0

Why this looks like the driver and not the DT

phy@88e1000 has no DWC3 behind it. The USB controllers on this board are
a400000.usb (multiport), a600000.usb and a800000.usb; none is the tertiary
instance phy@88e1000 would pair with. That PHY is DisplayPort-only here,
and every tertiary clock sits at an enable count of 0 while the two PHYs
that do have controllers sit at 1:

	                                en prep     rate     hw  consumer
	gcc_usb3_tert_phy_com_aux_clk    0   0    19200000   Y   88e1000.phy
	gcc_usb3_tert_phy_aux_clk        0   0    19200000   N   88e1000.phy
	gcc_usb3_tert_phy_pipe_clk       0   0   125000000   N   88e1000.phy
	gcc_usb3_sec_phy_com_aux_clk     1   1    19200000   Y   fde000.phy
	gcc_usb3_prim_phy_com_aux_clk    1   1    19200000   Y   fd5000.phy

com_aux reports hw_enable = Y at an enable count of 0 -- the hardware reads
as on while nothing in the framework has enabled it, which is what I would
expect if clk_branch_toggle() polls the halt bit and times out at -EBUSY.

qmp_combo_clk_init() fetches {aux, cfg_ahb, ref, com_aux} with
devm_clk_bulk_get_optional(), and qmp_combo_com_init() enables the whole
bulk unconditionally -- including com_aux, which on this instance never
comes out of halt.

I cannot say from outside the SoC why it does not, but I can narrow it. It
is not a shared vote: gcc_usb3_tert_phy_com_aux_clk is BRANCH_HALT with
enable_reg == halt_reg == 0xe1074, its own CBCR rather than a bit in a vote
register, so enabling it waits on no other master. Its source is
gcc_usb3_tert_phy_aux_clk_src, an XO-derived RCG, at enable count 0 here
while the secondary instance's equivalent sits at 2. That leaves the
block's own power/reset state, which on the two working instances is
brought up by the DWC3 controller this one does not have. I would rather be
told the mechanism than guess at it, which is much of why I am writing.

Dropping com_aux from that node's clocks/clock-names makes the PHY
initialise cleanly: no clk-branch warnings, EDID 0 -> 512 bytes, modes
0 -> 32. That is legal, since the bulk get is _optional and cfg_ahb already
demonstrates it -- cfg_ahb is absent from all three combo PHY nodes here and
nothing complains. I do not think it is the right fix, though: the DT
describes the PHY's clocks correctly, and it is the driver that enables them
all regardless of whether the instance has a USB half.

Reproduced on the merged upstream A16 DTS

The machine daily-drives linux-next next-20260807 booting the merged board
file, e8fbbca94db7 ("arm64: dts: qcom: glymur: Add Asus Zenbook A16
(UX3607OA)"), which builds standalone. It fails identically, and everything
above is from that boot. The only local DT delta is an unrelated
arm,no-completion-irq on the SCMI transport.

Konrad, the merged commit lists the HDMI port as working, and it does not
work here, so I am sure I am missing something on my side: kernel revision,
a prerequisite, or a difference between units. One thing I can rule out --
booting your merged DTS, the board brings up all three USB controllers
including &usb_mp, so that is not it. Any pointer on what to check next
would be welcome.

Also, msm_dp_aux_transfer does not time out when the PHY is down

This is the part I would most like help with, because it turns a dead output
into a dead machine. With com_aux present, plugging a display in puts the DP
IRQ thread into uninterruptible sleep, and the compositor follows it in:

	STAT  PID   WCHAN                  COMMAND
	D     480   -                      irq/230-dp_display_isr
	Dl+   4855  msm_dp_aux_transfer    Hyprland

	# /proc/480/stack
	[<0>] msm_dp_aux_transfer+0x1e4/0x868 [msm]
	[<0>] drm_dp_dpcd_access+0x84/0x1a0 [drm_display_helper]
	[<0>] drm_dp_dpcd_probe+0x50/0x150 [drm_display_helper]
	[<0>] drm_dp_dpcd_read+0x12c/0x240 [drm_display_helper]
	[<0>] drm_dp_read_dpcd_caps+0x48/0x270 [drm_display_helper]
	[<0>] msm_dp_display_process_hpd_high.isra.0+0x50/0x240 [msm]
	[<0>] msm_dp_hpd_plug_handle.isra.0+0x84/0x198 [msm]
	[<0>] msm_dp_bridge_hpd_notify+0x94/0x2a0 [msm]

The AUX transfer is waiting on hardware that was never initialised -- the
"phy_power_on was called before phy_init" above is the same fact from the
other end -- and it never gives up. The compositor holds the DRM master lock
while stuck, so SIGKILL does not land and the session cannot be recovered.

It is not specific to hotplug: rebooting with the display attached brings
the machine up already wedged, same two tasks in the same function, with
phy_power_on-before-phy_init logged at 2.3s and 11.8s. An attached HDMI
display is enough to make the graphical session unusable from power-on, with
no user action at all. It took a cold boot with the cable out to recover.

An AUX transfer that cannot complete because the PHY is down seems like
something that should fail rather than block forever, independently of
whatever is wrong with com_aux. I have put the msm display maintainers on Cc
rather than writing separately, since both halves are the same event seen
from either side -- happy to split it out if you would rather keep the PHY
thread clean.

Environment

  - ASUS Zenbook A16 UX3607OA, Snapdragon X2 Elite Extreme (glymur/X2E94100)
  - linux-next next-20260807, merged upstream board DTS
  - HDMI chain: hdmi-connector <- Parade PS185 (simple-bridge)
    <- mdss_dp2 (af64000) <- phy@88e1000
  - Reproduces on every boot

I have the hardware and use it daily, so I am happy to test a patch or dump
any register state that would help.

I should be upfront that I am a hobbyist rather than a kernel developer, and
this work was AI-assisted. The measurements are real and reproducible;
please weigh my interpretation of them accordingly.

Thanks,

Jesse Casco