[Intel-gfx] [PATCH] drm/i915: prefer wide & slow to fast & narrow in DP configs

[Adam Jackson]

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.sig>