From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read Date: Fri, 17 Oct 2014 12:06:12 +0300 Message-ID: <20141017090612.GQ4284@intel.com> References: <1413481570-18288-1-git-send-email-ville.syrjala@linux.intel.com> <54401EF1.4060908@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 62EE26E30F for ; Fri, 17 Oct 2014 02:06:16 -0700 (PDT) Content-Disposition: inline In-Reply-To: <54401EF1.4060908@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Todd Previte Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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. > = > Reviewed-by: Todd Previte > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- = Ville Syrj=E4l=E4 Intel OTC