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

[Dmitry Baryshkov]

On Sun, Nov 08, 2026 at 10:15:01AM +0900, Joonhoe Kim wrote:
> 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().

This looks ok. Would you please send this change as a proper patch?

> 
> 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@xxxxxxxxxxxxxxxx/
> 
> Thanks,
> Joonhoe Kim

-- 
With best wishes
Dmitry