On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote: > On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard <keithp at keithp.com> wrote: > > Jesse Barnes <jbarnes at virtuousgeek.org> writes: > > > > > High frequency link configurations have the potential to cause trouble > > > with long and/or cheap cables, so prefer slow and wide configurations > > > instead. This patch has the potential to cause trouble for eDP > > > configurations that lie about available lanes, so if we run into that we > > > can make it conditional on eDP. Have we considered looking at the link quality bits of DPCD for this? Section 2.5.3.5 of the DP 1.1 spec looks apropos. It looks painfully slow to get all the way to the actual spec error rate, but it might not be a bad first test to run for a second before doing actual link training. Do you have a crappy cable that produces this problem? There's also a comment about the sink clearing the symbol lock and lane alignment bits on too many errors (3.5.1.3.2); we're not periodically re-checking those bits, maybe we should. It's a shame they didn't bother to spec anything actually good, like "sink must report the number of ECC corrections it's done". But I suppose that applies to DP as a whole really. > > I *have* run into this on eDP machines already, which is why the code > > loops this way today... > > It was structured to minimise lane count because certain chipsets did > not wire up all the lanes, right? Is that still relevant as we are using > the advertised max_lane_count from the DPCD now? Pretty sure it's structured to use minimum lane count because that's the correct thing to do for power. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120622/02f42886/attachment.pgp>
