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 <[email protected]> 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 <[email protected]> > > --- > > 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
signature.asc
Description: PGP signature
