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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #15 from Martin Peres <martin.peres at free.fr> ---
(In reply to Manasi from comment #14)
> (In reply to Martin Peres from comment #11)
> > (In reply to Manasi from comment #10)
> > > But if the aux transactions are failing then it is a real failure and we
> > > should not try the fallback I think.
> > > So how do we differentiate between this error and the actual link training
> > > error.
> > > 
> > > Manasi
> > 
> > Could we set a work item that would wait for 250ms and try again the
> > mode-set, and only set the link-training issue at this point?
> > 
> > I mean, if a panel does not answer to AUX requests, it is probably not up
> > yet, right?
> 
> Hi Martin,
> 
> But that should happen even before starting the link training, if the AUX is
> not up yet, then we should not go ahead and do the clock recovery phase at
> all, why not wait here for 250ms and then find some way to just fail without
> attempting link training.

I fully agree with the beginning. We should not go to the clock recovery phase
if we did not even go through link training at all.

However, not sure we can just wait there for 250ms before re-trying. This is a
question for a kernel developer, as I never even read this code.

> 
> I am trying to find out at what point can we first check for dp aux
> transactions and wait longer to try again?

Yes, that sounds like the right thing to do! Maybe Jani can chime in here :)

-- 
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/20170606/25dfcf98/attachment.html>