Bug 106529

I've tried the same thing with only the DP ultrawide monitor connected and got the same issue. dc logs, reading code and some kernel tracers (ftrace) on DC link training code basically tell me that the important part is this:

21:23:16 [drm] [LKTN]        [DP][ConnIdx:0] RBRx4 pass VS=2, PE=1^
21:23:16 [drm] link=0, dc_sink_in=          (null) is now Disconnected
21:23:18 [drm] [LKTN]        [DP][ConnIdx:0] HBRx4 pass VS=1, PE=0^
21:23:18 [drm] link=0, dc_sink_in=00000000dbbee48e is now Connected
21:23:18 [drm] [LKTN]        [DP][ConnIdx:0] RBRx4 pass VS=1, PE=1^

Whatever's going on with the first attempt at link training, it ends up with the monitor disconnecting (not sure if deliberately or by causing some error in the monitor; didn't dive deep enough into the code).

Pre-DC codepaths did not have an issue like this at all until Michel Dänzer created this patch: https://patchwork.freedesktop.org/patch/209464/ for bug 105308 thereby introducing a problem with the same effects (DC monitor gets disconnected on wakeup, which on multi-display causes issues) via a quite different approach (a deliberate DRM_MODE_DPMS_OFF & ON). But that should be a separate bug, I think.

And since Michel's patch got applied to all the kernels, the effect is that on any up to date 4.15+ kernel the same issue shows up whether you're doing dc=1 or dc=0, while the actual code paths causing it are different. (Which made this a PITA to figure out.)

Anyway, since I know nothing about DP link training and how to fix code relating to it, I've just bought a DP->HDMI cable thus "fixing" my problem entirely (including the second issue of a 2s lag with DP audio).

Hopefully someone in the future, a future man so to speak, will fix this issue eventually. Cause currently DP support is quite bad, it seems.

(In reply to Mariusz Mazur from comment #1)
> Pre-DC codepaths did not have an issue like this at all until Michel Dänzer
> created this patch: https://patchwork.freedesktop.org/patch/209464/ for bug
> 105308 thereby introducing a problem with the same effects (DC monitor gets
> disconnected on wakeup, which on multi-display causes issues) via a quite
> different approach (a deliberate DRM_MODE_DPMS_OFF & ON). But that should be
> a separate bug, I think.

FWIW, that change should have no direct effect on whether the display is considered connected or disconnected. The only change is that when the driver is notified that a DP display is "disconnected" (which can also happen without a physical disconnection, e.g. if the display is turned off), it doesn't immediately turn off the GPU's DP source anymore, but waits until either userspace asks to turn it off, or it gets notified that a display is "connected" again. Both "disconnect" / "connect" hotplug events are sent to userspace before and after this change. I suspect that immediately turning off the DP source simply happened to delay sending the "disconnect" hotplug event to userspace enough to avoid the issue on your system.

dc=1 codepath has the problem occur 100%  of the times the display wakes up (iirc).

dc=0 with your patch does not. It happens regularly, but not 100% of the times. Which I guess does indicate there's some timing issues involved.

I suspect it may have something to do with the pulse timing from the monitor.  Long pulses are for connect/disconnect events and short pulses are a feedback mechanism for the monitor to the driver.  I suspect the monitor is sending a short pulse that the driver is interpreting as a long pulse.

Maybe one thing we could do is delaying the sending of the disconnect hotplug event to userspace by some time (though at most until the next connect hotplug event).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/386.