Re: [PATCH v8 7/9] drm/msm/dp: handle the IRQ_HPD events reported by USB-C

[Joonhoe Kim <26rote@gmail.com>]

On Sat, 24 Oct 2026 03:35:23 +0300, Dmitry Baryshkov wrote:
> +		if (hpd_link_status == ISR_IRQ_HPD_PULSE_COUNT ||
> +		    event == DRM_CONNECTOR_DP_IRQ_HPD)
> +			msm_dp_irq_hpd_handle(dp);

With this, an IRQ_HPD that arrives while the link is down hangs the
board. I hit it on the Lenovo Y700 Gen 5 (TB323FU, Kaanapali), DP over
USB-C (pmic_glink altmode), when booting with a 5120x2160 SST monitor
attached. The tree is Linux v7.3 with this series (6/9 replaced by an
equivalent local change), the MST v7 series [1] and a few local fixes
outside this path.

The path itself is not new: the native HPD block can reach it through
ISR_IRQ_HPD_PULSE_COUNT. This patch makes it reachable from USB-C,
where every IRQ_HPD now goes there.

When the boot-time mode is disabled for the first modeset from
userspace, the monitor loses the link and sends an IRQ_HPD with
LINK_STATUS_UPDATED (DPCD 0x204 = 0x80). From a boot with the
active_stream_cnt check described below and drm.debug=0x100
(msm_dp_irq_hpd_handle() is inlined into msm_dp_bridge_hpd_notify()):

 [    4.572532] [drm:msm_dp_ctrl_off_link] disable
 [    4.573756] [drm:msm_dp_ctrl_link_clk_disable] disabled link clocks
 [    4.608443] msm_dpu 9801000.display-controller: [drm:msm_dp_bridge_hpd_notify] type=10 link hpd_link_status=0x0, status=1
 ...
 [    4.823192] [drm:msm_dp_link_process_link_status_update] channel_eq_done = 0, clock_recovery_done = 0
 [    4.823194] [drm:msm_dp_link_process_request] sink request=0x80
 [    4.823197] msm_dpu 9801000.display-controller: [drm:msm_dp_bridge_hpd_notify] sink_request=128
 [    4.823199] msm_dpu 9801000.display-controller: [drm:msm_dp_bridge_hpd_notify] 128
 [    4.823201] msm_dpu 9801000.display-controller: [drm:msm_dp_bridge_hpd_notify] After, type=10, sink_count=1

Without the check, msm_dp_display_handle_irq_hpd() calls
msm_dp_ctrl_handle_sink_request(), and msm_dp_ctrl_link_maintenance()
starts with msm_dp_ctrl_push_idle(), which writes REG_DP_STATE_CTRL
while the link clocks are off. The board hung on 3 of 3 boots with the
monitor attached. On the one hung boot with drm.debug, the printk ring
ends at the "128" line, the drm_dbg_dp() just before
msm_dp_ctrl_handle_sink_request(). In the two RAM dumps I could
analyse, CPU0 is still running pmic_glink_altmode_worker, which holds
the encoder's bridge_chain_mutex taken in
drm_bridge_connector_hpd_notify(), and ctrl->link_clks_on is false.

Locally I skip sink requests while the link is down. On this series
alone the check would be on power_on:

--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -400,3 +400,6 @@ static int msm_dp_display_handle_irq_hpd(struct msm_dp_display_private *dp)
 	drm_dbg_dp(dp->drm_dev, "%d\n", sink_request);
 
+	if (!dp->msm_dp_display.power_on)
+		return 0;
+
 	msm_dp_ctrl_handle_sink_request(dp->ctrl, dp->panel);

This matches the !power_on check that already guards
msm_dp_ctrl_push_idle() in msm_dp_display_atomic_disable().

In my tree the MST series replaces power_on with active_stream_cnt.
With the same check on active_stream_cnt, 2 of 2 boots came up on the
monitor; the link is retrained about 1.2 s later, when the stream is
enabled.

A check on ctrl->link_clks_on in msm_dp_ctrl_handle_sink_request()
should also work.

[1] https://lore.kernel.org/all/20260929-msm-dp-mst-v7-0-4b81473185e7@oss.qualcomm.com/

Thanks,
Joonhoe Kim