<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT][SKL] *ERROR* failed to enable link training" href="https://bugs.freedesktop.org/show_bug.cgi?id=101144#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BAT][SKL] *ERROR* failed to enable link training" href="https://bugs.freedesktop.org/show_bug.cgi?id=101144">bug 101144</a> from <a class="email" href="mailto:manasi.d.navare@intel.com" title="Manasi <manasi.d.navare@intel.com>"> Manasi</a> <pre> (In reply to Martin Peres from <a href="show_bug.cgi?id=101144#c11">comment #11</a>) > (In reply to Manasi from <a href="show_bug.cgi?id=101144#c10">comment #10</a>) > > 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 am trying to find out at what point can we first check for dp aux transactions and wait longer to try again? Manasi</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>