From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 106529] dc=1 kernels somehow trigger a disconnect of an lg ultrawide monitor during DP link training while attempting a wakeup Date: Thu, 09 Aug 2018 20:29:46 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1241236447==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id C14626E821 for ; Thu, 9 Aug 2018 20:29:46 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1241236447== Content-Type: multipart/alternative; boundary="15338465862.1c7BBA.23110" Content-Transfer-Encoding: 7bit --15338465862.1c7BBA.23110 Date: Thu, 9 Aug 2018 20:29:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D106529 --- Comment #1 from Mariusz Mazur --- 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=3D2, PE=3D1^ 21:23:16 [drm] link=3D0, dc_sink_in=3D (null) is now Disconnected 21:23:18 [drm] [LKTN] [DP][ConnIdx:0] HBRx4 pass VS=3D1, PE=3D0^ 21:23:18 [drm] link=3D0, dc_sink_in=3D00000000dbbee48e is now Connected 21:23:18 [drm] [LKTN] [DP][ConnIdx:0] RBRx4 pass VS=3D1, PE=3D1^ 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 erro= r 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=C3= =A4nzer 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 b= e 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= =3D1 or dc=3D0, while the actual code paths causing it are different. (Which mad= e 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 is= sue eventually. Cause currently DP support is quite bad, it seems. --=20 You are receiving this mail because: You are the assignee for the bug.= --15338465862.1c7BBA.23110 Date: Thu, 9 Aug 2018 20:29:46 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 1 on bug 10652= 9 from Mariusz Mazur 
I've tried the same thing with only the DP ultrawide monitor c=
onnected 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=3D2, PE=3D1^
21:23:16 [drm] link=3D0, dc_sink_in=3D          (null) is now Disconnected
21:23:18 [drm] [LKTN]        [DP][ConnIdx:0] HBRx4 pass VS=3D1, PE=3D0^
21:23:18 [drm] link=3D0, dc_sink_in=3D00000000dbbee48e is now Connected
21:23:18 [drm] [LKTN]        [DP][ConnIdx:0] RBRx4 pass VS=3D1, PE=3D1^

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 erro=
r 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=C3=
=A4nzer
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 shou=
ld 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=
=3D1
or dc=3D0, while the actual code paths causing it are different. (Which mad=
e 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 is=
sue
eventually. Cause currently DP support is quite bad, it seems.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15338465862.1c7BBA.23110-- --===============1241236447== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1241236447==--