Bug 41121

Created attachment 51519 [details] [review]
Boot with thunderbolt plugged in

Created attachment 51520 [details] [review]
boot with DVI plugged in

Created attachment 51521 [details] [review]
boot with DVI plugged in and thunderbolt inserted after about 30s

Created attachment 51522 [details] [review]
lspci -vv

Created attachment 51523 [details]
gzipped config

Ok, so some kernel version backtracking shows that this worked in 2.6.39.
I've run a bisect between 2.6.39 and 3.0-rc1, but I keep getting lost in the major displayport re-write that happened in there.

When the machine is booted using Bootcamp v4 directly (not via refit) the bios sets up the thunderbolt bridge, makes all the PCIe end devices visible on the system and wires the displayport through to the radeon.

I've added the regression tag to this bug.

I'm quite happy to spend time on irc running crash and burn cycles as required.

Further bisection reveals this commit broke it :

Commit 834b2904bbfde3d85b5e984688777d56e9c7bf80
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Fri May 20 04:34:24 2011 -0400

    drm/radeon/kms: improve aux error handling

    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>


Hacking the aux retries back in fixes it

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 7ad43c6..1a44aa9 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -60,11 +60,11 @@ 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;
@@ -77,8 +77,17 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan *chan,
 
        atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
 
-       *ack = args.v1.ucReplyStatus;
+   if (args.v1.ucReplyStatus && !args.v1.ucDataOutLen) {
+       if (args.v1.ucReplyStatus == 0x20 && retry_count++ < 10){
+                       printk("doing retry : %i\n",retry_count);
+           goto retry;}
+       DRM_DEBUG_KMS("failed to get auxch %02x%02x %02x %02x 0x%02x %02x after %d retries\n",
+             send[1], send[0], send[2], send[3],
+             chan->rec.i2c_id, args.v1.ucReplyStatus, retry_count);
+       return false;
+               }
 
+       *ack = args.v1.ucReplyStatus;
        /* timeout */
        if (args.v1.ucReplyStatus == 1) {
                DRM_DEBUG_KMS("dp_aux_ch timeout\n");
@@ -128,6 +137,7 @@ static int radeon_dp_aux_native_write(struct radeon_connector *radeon_connector,
        while (1) {
                ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
                                            msg, msg_bytes, NULL, 0, delay, &ack);
+               printk("aux_native_write : ret : %i\n",ret);
                if (ret < 0)
                        return ret;
                if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK)
@@ -158,6 +168,8 @@ 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);
+               
+               printk("aux_native_read : ret : %i\n",ret);
                if (ret == 0)
                        return -EPROTO;
                if (ret < 0)

Quite a few retries sprinkled through the log, so it appears it is required on some links.

[   16.365260] ADDRCONF(NETDEV_UP): eth2: link is not ready
[   17.393646] aux_native_read : ret : 8
[   17.592073] aux_native_read : ret : 0
[   17.604003] aux_native_read : ret : 0
[   17.612451] doing retry : 1
[   17.612689] aux_native_read : ret : 8
[   17.743642] aux_native_read : ret : 0
[   17.751633] aux_native_read : ret : 0
[   18.572898] tg3 0000:02:00.0: eth1: Link is up at 1000 Mbps, full duplex
[   18.572902] tg3 0000:02:00.0: eth1: Flow control is on for TX and on for RX
[   18.572905] tg3 0000:02:00.0: eth1: EEE is disabled
[   18.573642] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   19.078061] NET: Registered protocol family 17
[   19.116439] aux_native_read : ret : 8
[   19.299182] aux_native_read : ret : 0
[   19.307137] aux_native_read : ret : 0
[   19.315577] doing retry : 1
[   19.315815] aux_native_read : ret : 8
[   19.430797] aux_native_read : ret : 0
[   19.438793] aux_native_read : ret : 0
[   19.463489] aux_native_read : ret : 8
[   19.646190] aux_native_read : ret : 0
[   19.654164] aux_native_read : ret : 0
[   19.662574] doing retry : 1
[   19.662823] aux_native_read : ret : 8
[   19.781789] aux_native_read : ret : 0
[   19.789763] aux_native_read : ret : 0

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?

Fixed. Cheers Alex!

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1fd2a850ecad717113cb36fa9d6e4304cd19b89d

A patch referencing this bug report has been merged in Linux v3.1-rc9:

commit 109bc10d30f33e84f1d7289f0039e0c858ade82f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Oct 3 09:13:45 2011 -0400

    drm/radeon/kms: fix regression in DP aux defer handling