[Bug 110629] Intel i915 graphics driver issues with external monitor when laptop in docking station (opensuse bug 1132926)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110629

--- Comment #13 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Norman Golisz from comment #12)
> I've got the very same symptoms with my Thinkpad T430, 3 external monitors
> (Display Port) and docking station. In my case it's OpenBSD 6.5-current
> after my OS vendor updated the DRM code in April from Linux 4.4 to 4.19.34.
> 
> Part of my dmesg:
> 
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
> drm0 at inteldrm0
> inteldrm0: msi
> inteldrm0: 1920x1080, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> [drm] *ERROR* Link Training Unsuccessful
> 
> The last message is repeated 63 times.

That is a different issue.

otrebor's logs show that the MST link is getting retrained, which among other
things causes the FIFO underrun. I have zero faith that the current MST link
retraining can do its job properly. We need to rework that code to behave more
like the SST code. Ie. move the retraining to the hotplug work, make it grab
the appropriate locks for all the active streams going over the same link, make
sure it's not racing with ongoing commits, etc. Probably need to hoist the
locking higher up into the generic hotplug code so that we can handle the
multiple streams properly. Occasionally I've also pondered whether we shouldn't
just throw out the special case link retraining paths and just force a full
modeset for the pipe(s) in question.

In the meantime we could try to just get rid of the MST retraining code. But if
the link has truly failed this will just guarantee that you get no picture:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3aef12041672..ab2da1c8e1d9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4722,15 +4722,6 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
                bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
 go_again:
                if (bret == true) {
-
-                       /* check link status - esi[10] = 0x200c */
-                       if (intel_dp->active_mst_links > 0 &&
-                           !drm_dp_channel_eq_ok(&esi[10],
intel_dp->lane_count)) {
-                               DRM_DEBUG_KMS("channel EQ not ok,
retraining\n");
-                               intel_dp_start_link_train(intel_dp);
-                               intel_dp_stop_link_train(intel_dp);
-                       }
-
                        DRM_DEBUG_KMS("got esi %3ph\n", esi);
                        ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi,
&handled);

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190610/90561f4c/attachment-0001.html>