On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote:
>
> On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrj...@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.syrj...@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 <tprev...@gmail.com>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
