[Bug 107446] Monitor on 2nd DisplayPort is not initialized

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 21 16:09:47 UTC 2018


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

--- Comment #11 from Jan-Marek Glogowski <glogow at fbihome.de> ---
(In reply to Ville Syrjala from comment #10)
> (In reply to Ville Syrjala from comment #9)
> > The logs don't seem to make any real sense. With the current code we can see
> > the link retraining kicking in, but it fails for some reason. With the
> > proposed fix (which should really be more of a no-op because the current
> > code does have the code to retrain the link, just in a slightly different
> > place than before) we don't see any retraining happening.
> 
> Hmm. Seem I had the logs reversed. So with the fix we get the failed
> retraining once. And somehow that "fixes" things. In neither case do we see
> the sink signalling a hpd to indicate that the link has issues.

Yup - nothing tells the HW about the wrong link, just the unconditional call in
intel_dp_long_pulse detects it and retrains the link and settles on the lower
lane count with the higher rate. The original code had the additional debug
message:

[drm:intel_dp_check_link_status [i915]] DDI D: channel EQ not ok, retraining

$ grep "DP-3.*Training Pa" *_drm
dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4
dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2
dmesg-4.16.18_dual_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:61:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2
dmesg-4.17.11_dual_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4
dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 162000, Lane count = 4
dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2
dmesg_4.18rc7_dual_fixed_drm:[drm:intel_dp_start_link_train [i915]]
[CONNECTOR:72:DP-3] Link Training Passed at Link Rate = 270000, Lane count = 2

All this may also be flawy monitor HW / firmware, as it doesn't happen with all
of them.

Originally I even thought that the DP of the monitor might be broken, as I'm on
kernel 4.4 on Ubuntu Trusty, and some other of the same model just worked. But
since we have a few hundred or even thousand of them I was just happy to see
that kernel 4.15 with Ubuntu Bionic was working. So I thought it might be a
driver problem after all.

In the end I'm not able to verify anything from the HW side. I don't know if
this problem indicates really a HW problem or is just an accepted quality
margin in production of the monitor. It is broken in 4.4, working in 4.15 and
broken since 4.17 again.

These newer model of these monitors seem to have problems with DPMS, where they
report the wrong DPMS state (queried via xset q) and won't wake up on user
interaction (at least that's my unverified interpretation) and the user has to
power cycle them to get a picture after DPMS off.
That's the bug I would like to understand and fix, but I can not reproduce it
locally, even with HW from the users send in :-(

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


More information about the intel-gfx-bugs mailing list