Messages in this thread Patch in this message | | | Date | Thu, 29 Sep 2011 10:36:41 -0400 | Subject | Re: Radeon regression fix | From | Alex Deucher <> |
| |
On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell <brad@fnarfbargle.com> wrote: > This patch fixes a regression introduced between 2.6.39 & 3.1-rc1 whereby > the displayport AUX channel stopped re-trying commands that elicited a DEFER > response. >
It should still be retrying, just restructured slightly. The retry logic just moved into radeon_dp_i2c_aux_ch(), radeon_dp_aux_native_write(), and radeon_dp_aux_native_read(), e.g.,
else if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER) udelay(400);
Perhaps the delay is causing a problem. Does removing the udelay(400); help?
Alex
> Signed-off-by: Brad Campbell <brad@fnarfbargle.com> > > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c > b/drivers/gpu/drm/radeon/atombios_dp.c > index 7ad43c6..b8450f4 100644 > --- a/drivers/gpu/drm/radeon/atombios_dp.c > +++ b/drivers/gpu/drm/radeon/atombios_dp.c > @@ -60,11 +60,13 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan > *chan, > int index = GetIndexIntoMasterTable(COMMAND, > ProcessAuxChannelTransaction); > unsigned char *base; > int recv_bytes; > + int retry_count = 0; > > memset(&args, 0, sizeof(args)); > > base = (unsigned char *)rdev->mode_info.atom_context->scratch; > > +retry: > memcpy(base, send, send_bytes); > > args.v1.lpAuxRequest = 0; > @@ -79,6 +81,16 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan > *chan, > > *ack = args.v1.ucReplyStatus; > > + /* defer */ > + if (args.v1.ucReplyStatus == 0x20){ > + DRM_DEBUG_KMS("dp_aux_ch defer\n"); > + /* 10 is an arbitrary value from the pre-regression > patch > + in practice I've never seen more than one */ > + if (retry_count++ < 10) > + goto retry; > + return -EBUSY; > + } > + > /* timeout */ > if (args.v1.ucReplyStatus == 1) { > DRM_DEBUG_KMS("dp_aux_ch timeout\n"); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |