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");