On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell <brad@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
>
> 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");
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
