From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Jackson Subject: Re: [PATCH] drm/i915: prefer wide & slow to fast & narrow in DP configs Date: Fri, 22 Jun 2012 10:21:06 -0400 Message-ID: <1340374866.32292.66.camel@atropine> References: <1340316830-15601-1-git-send-email-jbarnes@virtuousgeek.org> <86pq8sqhcg.fsf@sumi.keithp.com> <1340355948_38587@CP5-2952> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1049228167==" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTP id 46EBD9E7C8 for ; Fri, 22 Jun 2012 07:21:17 -0700 (PDT) In-Reply-To: <1340355948_38587@CP5-2952> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1049228167== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4NsdkF9sT1g92PPUt0YE" --=-4NsdkF9sT1g92PPUt0YE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote: > On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard wro= te: > > Jesse Barnes writes: > >=20 > > > High frequency link configurations have the potential to cause troubl= e > > > 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... >=20 > 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 --=-4NsdkF9sT1g92PPUt0YE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk/kf1IACgkQW4otUKDs0NO6FgCfeVK5om4P6Ott+DMEL32K+WKH b/YAoKuV+HtU6blFgr2SeAVm81NURb4Y =uJiV -----END PGP SIGNATURE----- --=-4NsdkF9sT1g92PPUt0YE-- --===============1049228167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1049228167==--