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

[Dmitry Baryshkov]

On Sun, May 24, 2026 at 06:32:18PM -0300, Val Packett wrote:
> 
> On 5/24/26 7:33 AM, 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/
> > 
> > ---
> > Changes in v6:
> > - Corrected mismatch between Jessica's From and SoB emails
> > - Corrected documentation and fixed style comments for
> >    msm_dp_bridge_detect() (Bjorn, Konrad)
> > - Changed msm_dp_bridge_atomic_enable() to bail out earlier in case of
> >    link training failure (Konrad)
> > - Corrected commit message for the link training commit to stop
> >    mentioning event-related changes (Konrad)
> > - Added kerneldoc to msm_dp_display_host_phy_init(), describing return
> >    value (Konrad)
> > - Switched to guard() instead of raw mutex_lock() (Konrad)
> > - Link to v5: https://lore.kernel.org/r/20260314-hpd-refactor-v5-0-0c8450737d64@xxxxxxxxxxxxxxxx
> 
> Looks like v5 is already in linux-next.. merged in:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4d28d7f4c69895437aeb0337d5e8d3dc2a5395cf

To be replaced by v6 in the next linux-next buildup. There were comments
(and r-b's) by Konrad, so it was worth replacing the series rather than
forcing v5 through to msm-next and then drm-next and then landing
changes on top of it.

-- 
With best wishes
Dmitry