Re: [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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älä <ville.syrjala@linux.intel.com>
> >
> > 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älä <ville.syrjala@linux.intel.com>
> > ---
> >   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/intel_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 = 0; i < 3; i++) {
> >   		ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> >   		if (ret == 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 <tprevite@gmail.com>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC