Re: [PATCH v5 00/10] drm/msm/dp: Drop the HPD state machine

[Val Packett <val@packett.cool>]

On 3/14/26 9:51 PM, Val Packett wrote:
>
> On 3/13/26 10:09 PM, Dmitry Baryshkov wrote:
>> Currently, all HPD interrupt handling must go through the HPD state
>> machine.
>>
>> This has caused many issues where the DRM framework assumes that DP is
>> in one state while the state machine is stuck in another state.
>>
>> As discussed here [1], this series:
>>
>> - Removes the state machine
>> - Moves link training to atomic_enable()
>> - Changes the detect() behavior to return true if a display is 
>> physically
>>    plugged in (as opposed to if the DP link is ready).
>> - Remove event queue and move internal HPD handling to hpd_notify()
>>
>> To correctly detect the displays which are plugged on boot on the boards
>> which use dp-connector devices, this series depends on [2]. USB-C and
>> eDP panels are handled natively.
>>
>> [1] 
>> https://patchwork.freedesktop.org/patch/656312/?series=142010&rev=2#comment_1201738
>> [2] 
>> https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-0-786044cedc17@oss.qualcomm.com/
>
> Unfortunately this currently seems to mostly break link training with 
> USB-C, on x1e80100-dell-latitude-7455:
>
> [  102.190083] [drm:msm_dp_ctrl_link_train_1_2 [msm]] *ERROR* link 
> training #2 on phy 1 failed. ret=-110
> [  102.192846] [drm:msm_dp_ctrl_setup_main_link [msm]] *ERROR* link 
> training of LTTPR(s) failed. ret=-110
> [  102.211095] [drm:msm_dp_bridge_atomic_enable [msm]] *ERROR* Failed 
> link training (rc=-104)
> [  102.211164] [drm:msm_dp_aux_isr [msm]] *ERROR* Unexpected DP AUX 
> IRQ 0x01000000 when not busy
> [  102.247168] [drm:msm_dp_ctrl_link_train_1_2 [msm]] *ERROR* link 
> training #2 on phy 1 failed. ret=-110
> [  102.252859] [drm:msm_dp_ctrl_setup_main_link [msm]] *ERROR* link 
> training of LTTPR(s) failed. ret=-110
>
> [..]

Actually looks like that might've been due to having applied the [2] 
dp-connector series from above.

Removed it and rebooted, now plugging and unplugging multiple times 
between the 2 ports works fine.

Except unplug is still not reliable, the "ghost" monitor often remains 
after unplugging.

Almost nothing is logged to dmesg, literally I've only seen this line once:
[drm:msm_dp_panel_read_sink_caps [msm]] *ERROR* panel edid read failed

But I have unplugged the monitor now and I still see:

crtc[108]: crtc-1
         enable=1
         active=1
         self_refresh_active=0
         planes_changed=1
         mode_changed=0
         active_changed=0
         connectors_changed=0
         color_mgmt_changed=0
         plane_mask=2
         connector_mask=2
         encoder_mask=2
         mode: "3840x2560": 60 631750 3840 3888 3920 4000 2560 2563 2573 
2633 0x48 0x9
         lm[0]=2
         ctl[0]=1
         lm[1]=3
         ctl[1]=1
connector[38]: DP-2
         crtc=crtc-1
         [..]

and the compositor thinks it's still present, I can move the mouse to 
where the screen was etc.


~val