From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Previte Subject: Re: [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read Date: Fri, 17 Oct 2014 09:13:47 -0700 Message-ID: <5441403B.9080906@gmail.com> References: <1413481570-18288-1-git-send-email-ville.syrjala@linux.intel.com> <54401EF1.4060908@gmail.com> <20141017090612.GQ4284@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 29C236E351 for ; Fri, 17 Oct 2014 09:13:44 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so1040300pdb.17 for ; Fri, 17 Oct 2014 09:13:43 -0700 (PDT) In-Reply-To: <20141017090612.GQ4284@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: =?windows-1252?Q?Ville_Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On 10/17/2014 2:06 AM, Ville Syrj=E4l=E4 wrote: > On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote: >> On 10/16/2014 10:46 AM, ville.syrjala@linux.intel.com wrote: >>> From: Ville Syrj=E4l=E4 >>> >>> Sometimes we seem to get utter garbage from DPCD reads. The resulting >>> buffer is filled with the same byte, and the operation completed without >>> errors. My HP ZR24w monitor seems particularly susceptible to this >>> problem once it's gone into a sleep mode. >>> >>> The issue seems to happen only for the first AUX message that wakes the >>> sink up. But as the first AUX read we often do is the DPCD receiver >>> cap it does wreak a bit of havoc with subsequent link training etc. when >>> the receiver cap bw/lane/etc. information is garbage. >>> >>> A sufficient workaround seems to be to perform a single byte dummy read >>> before reading the actual data. I suppose that just wakes up the sink >>> sufficiently and we can just throw away the returned data in case it's >>> crap. DP_DPCD_REV seems like a sufficiently safe location to read here. >>> >>> Signed-off-by: Ville Syrj=E4l=E4 >>> --- >>> drivers/gpu/drm/i915/intel_dp.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/int= el_dp.c >>> index 64c8e04..f07f02c 100644 >>> --- a/drivers/gpu/drm/i915/intel_dp.c >>> +++ b/drivers/gpu/drm/i915/intel_dp.c >>> @@ -2870,6 +2870,13 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, = unsigned int offset, >>> ssize_t ret; >>> int i; >>> = >>> + /* >>> + * Sometime we just get the same incorrect byte repeated >>> + * over the entire buffer. Doing just one throw away read >>> + * initially seems to "solve" it. >>> + */ >>> + drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1); >>> + >>> for (i =3D 0; i < 3; i++) { >>> ret =3D drm_dp_dpcd_read(aux, offset, buffer, size); >>> if (ret =3D=3D size) >> Seems like a reasonable workaround for this problem, though >> investigating the actual root cause might be worthwhile. > Sure. If someone has an AUX analyzer and a HP ZR24w monitor it should > be trivial to look at the traffic and see if there's something bogus in > our AUX communication. Sadly I don't have an AUX analyzer. I've got the monitor on my desk but no AUX analyzer to use. I'll see if = I can track one down. -T >> Reviewed-by: Todd Previte >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx