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

From: Adam Jackson <ajax@redhat.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: prefer wide & slow to fast & narrow in DP configs
Date: Fri, 22 Jun 2012 10:21:06 -0400	[thread overview]
Message-ID: <1340374866.32292.66.camel@atropine> (raw)
In-Reply-To: <1340355948_38587@CP5-2952>

[-- Attachment #1.1: Type: text/plain, Size: 1694 bytes --]

On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote:
> On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard <keithp@keithp.com> wrote:
> > Jesse Barnes <jbarnes@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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx