On Sat, Mar 14, 2026 at 10:10:26PM -0300, Val Packett wrote: > > 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/[email protected]/ > > > > 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.
Interesting. The series only affects dp-connector. It can't affect pmic-glink usecase. > > 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. Does the patch at [3] fix the issue? [3] https://lore.kernel.org/linux-arm-msm/[email protected]/ > > 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 You might want to use drm.debug=0x100 to get DP-related messages. > > 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. -- With best wishes Dmitry
