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

[Val Packett]

On 3/17/26 10:03 PM, Dmitry Baryshkov wrote:
> On Tue, Mar 17, 2026 at 08:15:54PM -0300, Val Packett wrote:
> > On 3/16/26 12:23 AM, Dmitry Baryshkov wrote:
> > > 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/20260314-dp-connector-hpd-v1-0-786044cedc17@xxxxxxxxxxxxxxxx/
> > > > > 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/177362655076.7429.3868048981197120360.b4-ty@xxxxxxxxxx/
> > Yes!
> >
> > Overall works better than ever now, looks like I can unplug the cable with
> > the laptop closed and then open it and it's all fine, and even play with
> > dual-role / gadget mode USB and plug the alt-mode/dock cable back in and it
> > doesn't crash.
> Tested-by?

Yeah, since I guess the link training is kinda orthogonal to this, sure!

Tested-by: Val Packett <val@xxxxxxxxxxxx> # x1e80100-dell-latitude-7455

> > Still, rare link training failures can happen, e.g.:
> Thanks!
>
> The link training is one of the items that I want to check next.