On 07/24/2017 03:45 PM, Florian Echtler wrote:
Hello Lukas,
On 17.07.2017 11:02, Lukas Wunner wrote:
On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
Sorry for the delay Florian. Commit 564d8a2cf3ab by Mario Kleiner (+cc) landed in Linus' tree last week and is included in 4.13-rc1. It is supposed to fix black screen issues with the iMac10,1 that you're also using, though in Mario's case they seem to occur upon boot, rather than on suspend, still might be worth a try:
Hi,
thanks for the hint. I've applied this patch to the v4.12 tree I'm currently running, and it didn't seem to make any difference (i.e. display stays black after suspend).
That's the same here with my patch applied. After a suspend -> resume, the internal panel stays black, the patch doesn't help for that. Somethig i didn't notice btw., apparently i never suspend->resumed it.
Without the patch, when I plug in an external display (via MiniDP-to-DVI), then the internal panel stays black when booting, only the external display works.
That's different for me:
The internal panel always works during boot, until the radeon kms driver loads and modesetting gets initialized, then the panel goes dark.
With my patch, the panel then lights up properly immediately, and external output to dvi/hdmi works as well if i connect anything. External Displayport panel doesn't work though - stays dark, although it is reported connected+active in xrandr.
However this is something i got when connecting the external Displayport panel:
Jul 7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344792] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed Jul 7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344819] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed Jul 7 04:18:07 kleinerm-MaxtorLinux kernel: [ 1559.770783] drm_dp_i2c_do_msg: 20 callbacks suppressed Jul 7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143406] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed Jul 7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143439] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed Jul 7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356173] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed Jul 7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356205] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
So link training failed, because drm_dp_dpcd_read_link_status() already failed to read from the dp aux channel.
Without my patch the internal panel stays dark, but plugging in an external hdmi/dvi display gets both internal+external to light up.
Another way i was able to force the internal panel to stay on without my patch and without an external display connected is to use the kernel cmdline option "video=DP-1:2560x1440D" to force the external output on, although nothing is connected.
The patch is just the result of trial and error, following hunches, based on reading through the radeon modesetting code. Unfortunately no real insight into why stuff goes wrong. I also remember disassembling bits of the dumped atombios a year ago and not finding anything that looked suspicious to me, but then i'm not experienced at that.
Actually, the patch then makes things slightly worse in my case: with the patch applied, not even the external sink works anymore. When I log in remotely and run "DISPLAY=:0.0 xrandr", both DP connections are shown as active, but neither does actually show an image.
So the same machine model behaves differently with the same patch, and worse in your case than without it? Maybe different hardware or firmware?
Apples website lists two models of late 2009 iMac10,1 and Radeon HD 4670, to which the patch should apply. One 21.5 inch model without TDM and a 27 inch model with TDM. Mine is the 27 inch one. I assume yours as well due to TDM? Attached is the output of dmidecode on mine, not sure what to look for for differences?
Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.
I'd be grateful about a bit of background information here, I'd really like to help fix this.
Lukas idea that some hardware mux gets switched into the wrong position on models with TDM sounds pretty appealing to me, but how to test?
-mario
Best, Florian