[Bug 101144] [BAT][SKL] *ERROR* failed to enable link training

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jun 13 10:12:06 UTC 2017


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

--- Comment #23 from Marta Löfstedt <marta.lofstedt at intel.com> ---
(In reply to Manasi from comment #22)
> (In reply to Jani Nikula from comment #17)
> > (In reply to Manasi from comment #14)
> > > I am trying to find out at what point can we first check for dp aux
> > > transactions and wait longer to try again?
> > 
> > Can you explain how we'd end up in link training if native aux was failing
> > altogether? It must have worked for some time before link training, right?
> > 
> > Ville's explanation would cover this as well.
> 
> Actually it fails inside the function
> intel_dp_link_training_clock_reciovery() when it tries to write the TP1 and
> errors out saying "Failed to enable link training".
> Yes but it worked fine for DPCD reads over AUX, so that's why I am confused
> as to where we need to add the delay for the AUX reads?
> 
> Also, shouldn't the spec for that specific panel or the eDP spec talk about
> how much delay should be given for the AUX read/writes?
> Any thoughts on double checking this in the spec?
> 
> Manasi

Manasi, I believe that one theory is that device have actually become
broken/unstable and that we should try to prove this somehow.

If you or Ville has some ideas on how to prove/disprove this, could you try
this on the try-bot, or provide a patch that I can run on the machine early in
the morning when the CI is usually idle.

-- 
You are receiving this mail because:
You are the QA Contact 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/20170613/d2da6b97/attachment.html>


More information about the intel-gfx-bugs mailing list