Messages in this thread Patch in this message | | | Date | Fri, 30 Sep 2011 08:23:02 +0800 | From | Brad Campbell <> | Subject | Re: Radeon regression fix |
| |
On 29/09/11 23:21, Brad Campbell wrote: > On 29/09/11 22:36, Alex Deucher wrote: >> 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?
Looking at it with a nights sleep, it's obvious the code path in aux_native_write is ok. Is this a bit cleaner than the last patch?
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index 7ad43c6..aacc97d 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -158,14 +158,17 @@ static int radeon_dp_aux_native_read(struct radeon_connector *radeon_connector, while (1) { ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus, msg, msg_bytes, recv, recv_bytes, delay, &ack); - if (ret == 0) + if (ret == 0){ + if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER){ + udelay(400); + continue; + } return -EPROTO; + } if (ret < 0) return ret; if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK) return ret; - else if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER) - udelay(400); else return -EIO; }
| |