Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: retrain DP link directly on cable replug

[Maxime Ripard]

On Fri, Aug 14, 2026 at 10:14:42AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Aug 14, 2026 at 5:04 AM Yashas D <y-d@xxxxxx> wrote:
> >
> > When a cable is replugged while the upstream display pipeline is still
> > active (e.g. a compositor holds the CRTC), the bridge can retrain the
> > DP link and re-enable the video stream directly from the HPD interrupt
> > work handler without requiring a full DRM atomic commit. This allows
> > applications to recover display output after a cable replug.
> >
> > Signed-off-by: Yashas D <y-d@xxxxxx>
> > ---
> >  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 215 +++++++++++++++++++++-----
> >  1 file changed, 179 insertions(+), 36 deletions(-)
> 
> There's a lot of code here and Sashiko has a bunch of feedback [1].
> I'm not personally very familiar with the HPD flows. I'll probably
> skip reviewing this until Sashiko is reasonably happy or until you
> explain why Sashiko is confused.
> 
> FWIW, just from the patch description, I'd also question if this is
> really a good idea. If we get an unplug / replug, we could get an
> entirely new display plugged in. This is really something that's OK
> without needing to handle things?

The expectation is that the output should remain the same unless
userspace decides on a modeset. So, we should send the hotplug event,
and reenable the output as is.

I'm not sure if there's only link-training in DP's case, but for HDMI we
have a similar issue with the scrambling setup that gets reset by the
unplug/replug cycle.

The easier thing to do in that case is to create a new empty commit and
disable/enable the whole display chain starting with the CRTC, since it
doesn't create a new path to test. We have
drm_atomic_helper_reset_crtc() and drm_bridge_helper_reset_crtc() to do
just that.

Maxime

Attachment: signature.asc
Description: PGP signature