https://bugs.freedesktop.org/show_bug.cgi?id=41121
Summary: Apple Thunderbolt display is not initialized when plugged into iMac 12,2 (Radeon 6870) Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: brad@fnarfbargle.com
Created an attachment (id=51518) --> (https://bugs.freedesktop.org/attachment.cgi?id=51518) Clean boot with nothing plugged in
This iMac has 2 "Thunderbolt" (mini-displayport connectors on the back). They will happily drive a pair of 1920x1200 DVI monitors with mini-displayport to DVI dongles, but will not look at the Apple "thunderbolt" monitor when plugged in.
It does work in OSX however.
If the monitor is plugged in at boot, the kernel appears to read the EDID correctly (the modes are displayed as what they should be), however it always fails to bring the displayport link up.
I've included 4 dmesg runs from clean boot to a single user console. 1) clean with no external monitors 2) clean with thunderbolt monitor at boot 3) clean with DVI at boot 4) (3) but with thunderbolt plugged in at about the 30s point. (This often reduces the machine to a steaming pile of molasses, almost like an interrupt storm but with no outward signs except a very slow console/processing.
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #1 from Brad Campbell brad@fnarfbargle.com 2011-09-22 07:40:57 PDT --- Created an attachment (id=51519) --> (https://bugs.freedesktop.org/attachment.cgi?id=51519) Boot with thunderbolt plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #2 from Brad Campbell brad@fnarfbargle.com 2011-09-22 07:41:25 PDT --- Created an attachment (id=51520) --> (https://bugs.freedesktop.org/attachment.cgi?id=51520) boot with DVI plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #3 from Brad Campbell brad@fnarfbargle.com 2011-09-22 07:41:59 PDT --- Created an attachment (id=51521) --> (https://bugs.freedesktop.org/attachment.cgi?id=51521) boot with DVI plugged in and thunderbolt inserted after about 30s
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #4 from Brad Campbell brad@fnarfbargle.com 2011-09-22 07:43:34 PDT --- Created an attachment (id=51522) --> (https://bugs.freedesktop.org/attachment.cgi?id=51522) lspci -vv
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #5 from Brad Campbell brad@fnarfbargle.com 2011-09-22 07:43:54 PDT --- Created an attachment (id=51523) --> (https://bugs.freedesktop.org/attachment.cgi?id=51523) gzipped config
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51519|application/octet-stream |text/plain mime type| | Attachment #51519|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51520|application/octet-stream |text/plain mime type| | Attachment #51520|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51521|application/octet-stream |text/plain mime type| | Attachment #51521|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51522|application/octet-stream |text/plain mime type| | Attachment #51522|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51518|application/octet-stream |text/plain mime type| | Attachment #51518|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Brad Campbell brad@fnarfbargle.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #6 from Brad Campbell brad@fnarfbargle.com 2011-09-28 00:39:56 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #7 from Brad Campbell brad@fnarfbargle.com 2011-09-29 03:46:09 PDT --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #8 from Alex Deucher agd5f@yahoo.com 2011-09-29 08:01:27 PDT --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=41121
Brad Campbell brad@fnarfbargle.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #9 from Brad Campbell brad@fnarfbargle.com 2011-10-04 21:57:12 PDT --- Fixed. Cheers Alex!
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1fd2...
https://bugs.freedesktop.org/show_bug.cgi?id=41121
--- Comment #10 from Florian Mickler florian@mickler.org 2011-10-06 05:53:17 PDT --- 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
dri-devel@lists.freedesktop.org