[cc += dri-devel, amd-gfx]
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
Note: this appears to be entirely unrelated to the TDM stuff I posted about earlier. Interestingly, when I enable TDM, even after suspend, the display works while TDM is active. Once I disable TDM, it's back to black (unintentional song reference there).
Sounds like a radeon issue to me.
The LCD_PANEL_PWR and LCD_BKL_ON_MUX pins are coming from a mux.
In TDM mode, the pins are muxed to the SMC, so it can turn the panel on and off. If TDM is not in use, the pins are muxed to the ATI card.
The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins. Those must be enabled for the panel to light up. Perhaps radeon needs to be extended to do that. One theory is that this is done via ACPI, but perhaps only if a certain operating system is running. Dump the ACPI tables and search DSDT and SSDT* tables for methods relating to the ATI card and/or backlight. If you find checks for OSDW there (e.g. in _PS0, i.e. on resume), it means the AML code is only executed on Darwin. Conversely !OSDW means the code is only executed on Windows (Boot Camp). Linux masquerades as Darwin, but this can be disabled with acpi_osi=!Darwin on the command line. It's worth trying if that changes the behaviour. If it does, then macOS likely sets those pins on resume and we need to do the same in radeon.
HTH,
Lukas
I've noted that in /sys/class/backlight, there are two different control interfaces, apple_backlight and radeon_bl0. Before suspend, I can control the screen brightness from system settings, even if only one of them is loaded, so both brightness interfaces work.
What I've already tried without success:
- Blindly switching to the console and back.
- Calling DISPLAY=:0.0 xrandr --output eDP1 --auto via ssh.
- Restarting X via ssh.
- Blacklist apple_bl on the kernel cmdline (modprobe.blacklist=apple_bl).
- Disabling the radeon backlight on the kernel cmdline (radeon.backlight=0).
- Using radeontool to turn the backlight back on after suspend.
- Directly using the interface in /sys/class/backlight/ to turn it back on.
I'm starting to run out of ideas... any hints?
Regards, Florian
SENT FROM MY DEC VT50 TERMINAL
On 26.05.2017 23:03, Lukas Wunner wrote:
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins. Those must be enabled for the panel to light up. Perhaps radeon needs to be extended to do that. One theory is that this is done via ACPI, but perhaps only if a certain operating system is running. Dump the ACPI tables and search DSDT and SSDT* tables for methods relating to the ATI card and/or backlight. If you find checks for OSDW there (e.g. in _PS0, i.e. on resume), it means the AML code is only executed on Darwin.
I've already had a look at the ACPI tables; there seem to be no references to the "official" backlight/display control functions (no _BL? or _DO? methods).
Conversely !OSDW means the code is only executed on Windows (Boot Camp). Linux masquerades as Darwin, but this can be disabled with acpi_osi=!Darwin on the command line. It's worth trying if that changes the behaviour. If it does, then macOS likely sets those pins on resume and we need to do the same in radeon.
There are OSDW checks present, however, booting with acpi_osi=!Darwin doesn't make a difference to the backlight behaviour.
I'd be grateful for other suggestions...
Best regards, Florian
On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
On 26.05.2017 23:03, Lukas Wunner wrote:
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins. Those must be enabled for the panel to light up. Perhaps radeon needs to be extended to do that. One theory is that this is done via ACPI, but perhaps only if a certain operating system is running. Dump the ACPI tables and search DSDT and SSDT* tables for methods relating to the ATI card and/or backlight. If you find checks for OSDW there (e.g. in _PS0, i.e. on resume), it means the AML code is only executed on Darwin.
I've already had a look at the ACPI tables; there seem to be no references to the "official" backlight/display control functions (no _BL? or _DO? methods).
Conversely !OSDW means the code is only executed on Windows (Boot Camp). Linux masquerades as Darwin, but this can be disabled with acpi_osi=!Darwin on the command line. It's worth trying if that changes the behaviour. If it does, then macOS likely sets those pins on resume and we need to do the same in radeon.
There are OSDW checks present, however, booting with acpi_osi=!Darwin doesn't make a difference to the backlight behaviour.
So, just to confirm, if you never plug in an external DP source and the iMac comes out of sleep, the display stays black?
If you log in via ssh and look at dmesg, was radeon able to train the DP link again? No error messages, nothing?
Is the panel off or is it on but merely with 0% brightness?
There's a block of pins on the GPU for "system management" which contains a bunch of GPIO, OEM and reserved pins. Three of these are used to control the panel when it's switched to the radeon card: pin 23 PNL_PWR_EN pin 25 PNL_BL_EN pin 27 PNL_BL_PWM
Basically you'd need to know what these are set to before and after sleep. I don't know how to access them, presumably via a BAR register. A quick look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not yield anything useful, but someone at AMD may be able to find this out.
Maybe these registers are supposed to be modified by the OS when coming out of sleep, or they're modified by video BIOS but the OS has to trigger this somehow.
HTH,
Lukas
On 30.05.2017 12:54, Lukas Wunner wrote:
On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
On 26.05.2017 23:03, Lukas Wunner wrote:
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
So, just to confirm, if you never plug in an external DP source and the iMac comes out of sleep, the display stays black?
Correct, verified this just now.
If you log in via ssh and look at dmesg, was radeon able to train the DP link again? No error messages, nothing?
Here are the relevant dmesg lines after wakeup:
[ 157.622950] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000). [ 157.626094] radeon 0000:02:00.0: WB enabled [ 157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00 [ 157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c [ 157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffbc3081c1c598 [ 157.672183] [drm] ring test on 0 succeeded in 1 usecs [ 157.672187] [drm] ring test on 3 succeeded in 2 usecs [ 157.847098] [drm] ring test on 5 succeeded in 1 usecs [ 157.847102] [drm] UVD initialized successfully. [ 157.847121] [drm] ib test on ring 0 succeeded in 0 usecs [ 157.847136] [drm] ib test on ring 3 succeeded in 0 usecs [ 158.524061] [drm] ib test on ring 5 succeeded
And this is logged in Xorg.0.log after wakeup:
[ 229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384 [ 229.956] (II) RADEON(0): VRAM usage limit set to 219596K
xrandr still shows the eDP output as connected and active with 2560x1440 resolution.
Is the panel off or is it on but merely with 0% brightness?
The backlight is definitely off. I've tried to shine a torch onto the panel and see if any content is visible, but it looks like the panel itself is off, too.
There's a block of pins on the GPU for "system management" which contains a bunch of GPIO, OEM and reserved pins. Three of these are used to control the panel when it's switched to the radeon card: pin 23 PNL_PWR_EN pin 25 PNL_BL_EN pin 27 PNL_BL_PWM
Basically you'd need to know what these are set to before and after sleep. I don't know how to access them, presumably via a BAR register. A quick look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not yield anything useful, but someone at AMD may be able to find this out.
Can I perhaps use radeontool for this? I.e. dump registers before and after sleep and see if there's a difference? Or is radeontool too old to know about the correct registers?
Best, Florian
On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
On 30.05.2017 12:54, Lukas Wunner wrote:
On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
On 26.05.2017 23:03, Lukas Wunner wrote:
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
So, just to confirm, if you never plug in an external DP source and the iMac comes out of sleep, the display stays black?
Correct, verified this just now.
If you log in via ssh and look at dmesg, was radeon able to train the DP link again? No error messages, nothing?
Here are the relevant dmesg lines after wakeup:
[ 157.622950] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000). [ 157.626094] radeon 0000:02:00.0: WB enabled [ 157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00 [ 157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c [ 157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffbc3081c1c598 [ 157.672183] [drm] ring test on 0 succeeded in 1 usecs [ 157.672187] [drm] ring test on 3 succeeded in 2 usecs [ 157.847098] [drm] ring test on 5 succeeded in 1 usecs [ 157.847102] [drm] UVD initialized successfully. [ 157.847121] [drm] ib test on ring 0 succeeded in 0 usecs [ 157.847136] [drm] ib test on ring 3 succeeded in 0 usecs [ 158.524061] [drm] ib test on ring 5 succeeded
Hm, try booting with drm.debug=0xf to see if link training for the eDP connector succeeds. If the link cannot be trained, it would explain that the screen stays black. Should this indeed be the case, one possible explanation would be that the panel is muxed to the external port on resume and an appropriate command needs to be sent to the SMC to switch the mux to the radeon card. This could be done in the ->resume_early hook of your APP000C platform driver. The apple-gmux driver contains something similar to power the discrete GPU down if it was off before suspend (because the BIOS always powers it up on resume).
Another possible explanation would be that panel power needs to be enabled by writing to the registers which control the pins mentioned below.
And this is logged in Xorg.0.log after wakeup:
[ 229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384 [ 229.956] (II) RADEON(0): VRAM usage limit set to 219596K
xrandr still shows the eDP output as connected and active with 2560x1440 resolution.
Is the panel off or is it on but merely with 0% brightness?
The backlight is definitely off. I've tried to shine a torch onto the panel and see if any content is visible, but it looks like the panel itself is off, too.
There's a block of pins on the GPU for "system management" which contains a bunch of GPIO, OEM and reserved pins. Three of these are used to control the panel when it's switched to the radeon card: pin 23 PNL_PWR_EN pin 25 PNL_BL_EN pin 27 PNL_BL_PWM
Basically you'd need to know what these are set to before and after sleep. I don't know how to access them, presumably via a BAR register. A quick look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not yield anything useful, but someone at AMD may be able to find this out.
Can I perhaps use radeontool for this? I.e. dump registers before and after sleep and see if there's a difference? Or is radeontool too old to know about the correct registers?
*shrug* Unfortunately I'm not familiar at all with radeontool. :-(
Best regards,
Lukas
On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner lukas@wunner.de wrote:
On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
On 30.05.2017 12:54, Lukas Wunner wrote:
On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
On 26.05.2017 23:03, Lukas Wunner wrote:
On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even with the most recent HWE stack (kernel 4.8), the display stays black after suspend. I can ssh into the machine, so wakeup is OK, but the display is entirely black (backlight stays off).
So, just to confirm, if you never plug in an external DP source and the iMac comes out of sleep, the display stays black?
Correct, verified this just now.
If you log in via ssh and look at dmesg, was radeon able to train the DP link again? No error messages, nothing?
Here are the relevant dmesg lines after wakeup:
[ 157.622950] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000). [ 157.626094] radeon 0000:02:00.0: WB enabled [ 157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00 [ 157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c [ 157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffbc3081c1c598 [ 157.672183] [drm] ring test on 0 succeeded in 1 usecs [ 157.672187] [drm] ring test on 3 succeeded in 2 usecs [ 157.847098] [drm] ring test on 5 succeeded in 1 usecs [ 157.847102] [drm] UVD initialized successfully. [ 157.847121] [drm] ib test on ring 0 succeeded in 0 usecs [ 157.847136] [drm] ib test on ring 3 succeeded in 0 usecs [ 158.524061] [drm] ib test on ring 5 succeeded
Hm, try booting with drm.debug=0xf to see if link training for the eDP connector succeeds. If the link cannot be trained, it would explain that the screen stays black. Should this indeed be the case, one possible explanation would be that the panel is muxed to the external port on resume and an appropriate command needs to be sent to the SMC to switch the mux to the radeon card. This could be done in the ->resume_early hook of your APP000C platform driver. The apple-gmux driver contains something similar to power the discrete GPU down if it was off before suspend (because the BIOS always powers it up on resume).
Another possible explanation would be that panel power needs to be enabled by writing to the registers which control the pins mentioned below.
And this is logged in Xorg.0.log after wakeup:
[ 229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384 [ 229.956] (II) RADEON(0): VRAM usage limit set to 219596K
xrandr still shows the eDP output as connected and active with 2560x1440 resolution.
Is the panel off or is it on but merely with 0% brightness?
The backlight is definitely off. I've tried to shine a torch onto the panel and see if any content is visible, but it looks like the panel itself is off, too.
There's a block of pins on the GPU for "system management" which contains a bunch of GPIO, OEM and reserved pins. Three of these are used to control the panel when it's switched to the radeon card: pin 23 PNL_PWR_EN pin 25 PNL_BL_EN pin 27 PNL_BL_PWM
Basically you'd need to know what these are set to before and after sleep. I don't know how to access them, presumably via a BAR register. A quick look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not yield anything useful, but someone at AMD may be able to find this out.
Can I perhaps use radeontool for this? I.e. dump registers before and after sleep and see if there's a difference? Or is radeontool too old to know about the correct registers?
*shrug* Unfortunately I'm not familiar at all with radeontool. :-(
You can use the radeonreg tool to dump the display registers: https://cgit.freedesktop.org/~agd5f/radeontool/ radeonreg regs dce3 replace dce3 with whatever dce version your card has.
Alex
On 31.05.2017 14:57, Alex Deucher wrote:
On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner lukas@wunner.de wrote:
On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
Hm, try booting with drm.debug=0xf to see if link training for the eDP connector succeeds. If the link cannot be trained, it would explain that the screen stays black. Should this indeed be the case, one possible explanation would be that the panel is muxed to the external port on resume and an appropriate command needs to be sent to the SMC to switch the mux to the radeon card. This could be done in the ->resume_early hook of your APP000C platform driver. The apple-gmux driver contains something similar to power the discrete GPU down if it was off before suspend (because the BIOS always powers it up on resume).
Here's the (substantial) dmesg output, with drm.debug=0xf: http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
I haven't been able to find any references to link training, though.
*shrug* Unfortunately I'm not familiar at all with radeontool. :-(
You can use the radeonreg tool to dump the display registers: https://cgit.freedesktop.org/~agd5f/radeontool/ radeonreg regs dce3 replace dce3 with whatever dce version your card has.
AFAICT the RV730 indeed has dce3, so I created a register dump before and after suspend: http://floe.butterbrot.org/external/radeon/regs_before_suspend.txt http://floe.butterbrot.org/external/radeon/regs_after_suspend.txt
The diff, however, is quite large, I have no idea which registers to look for.
Best, Florian
On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler floe@butterbrot.org wrote:
On 31.05.2017 14:57, Alex Deucher wrote:
On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner lukas@wunner.de wrote:
On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
Hm, try booting with drm.debug=0xf to see if link training for the eDP connector succeeds. If the link cannot be trained, it would explain that the screen stays black. Should this indeed be the case, one possible explanation would be that the panel is muxed to the external port on resume and an appropriate command needs to be sent to the SMC to switch the mux to the radeon card. This could be done in the ->resume_early hook of your APP000C platform driver. The apple-gmux driver contains something similar to power the discrete GPU down if it was off before suspend (because the BIOS always powers it up on resume).
Here's the (substantial) dmesg output, with drm.debug=0xf: http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
I haven't been able to find any references to link training, though.
I need your dmesg from boot to confirm the display topology, but eDP with r7xx asics was pretty rare. I suspect your system just uses LVDS; as such there is no link training involved.
Alex
*shrug* Unfortunately I'm not familiar at all with radeontool. :-(
You can use the radeonreg tool to dump the display registers: https://cgit.freedesktop.org/~agd5f/radeontool/ radeonreg regs dce3 replace dce3 with whatever dce version your card has.
AFAICT the RV730 indeed has dce3, so I created a register dump before and after suspend: http://floe.butterbrot.org/external/radeon/regs_before_suspend.txt http://floe.butterbrot.org/external/radeon/regs_after_suspend.txt
The diff, however, is quite large, I have no idea which registers to look for.
Best, Florian
SENT FROM MY DEC VT50 TERMINAL
On 01.06.2017 19:53, Alex Deucher wrote:
On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler floe@butterbrot.org wrote:
On 31.05.2017 14:57, Alex Deucher wrote:
On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner lukas@wunner.de wrote:
Here's the (substantial) dmesg output, with drm.debug=0xf: http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
I haven't been able to find any references to link training, though.
I need your dmesg from boot to confirm the display topology, but eDP with r7xx asics was pretty rare. I suspect your system just uses LVDS; as such there is no link training involved.
I've updated the trace with increased log_buf_len so nothing is truncated:
http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt
(trace now contains a full boot including suspend and wakeup)
However, what I'm seeing now does sound like the internal connection is indeed eDP:
[ 166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0] [ 166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1] [ 166.816167] [drm:drm_crtc_helper_set_config] [ 166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54] #connectors=1 (x y) (0 0) [ 166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [ 166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4) [ 166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [ 166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [ 166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to [CRTC:34:crtc-0] [ 166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [ 166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x0 0x9 [ 166.816180] [drm:radeon_encoder_set_active_device] setting active device to 00000002 from 00000002 00000002 for encoder 3 [ 166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0] [ 166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices 00000008, active_devices 00000000 [ 166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, devices 00000010, active_devices 00000000 [ 166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816237] [drm:radeon_compute_pll_avivo] 360000 - 360000, pll dividers - fb: 80.0 ref: 2, post 3 [ 166.824475] done.
... and a bit later:
[ 166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0 pre-emphasis 0 [ 166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0
Best, Florian
On Fri, Jun 2, 2017 at 3:35 AM, Florian Echtler floe@butterbrot.org wrote:
On 01.06.2017 19:53, Alex Deucher wrote:
On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler floe@butterbrot.org wrote:
On 31.05.2017 14:57, Alex Deucher wrote:
On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner lukas@wunner.de wrote:
Here's the (substantial) dmesg output, with drm.debug=0xf: http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
I haven't been able to find any references to link training, though.
I need your dmesg from boot to confirm the display topology, but eDP with r7xx asics was pretty rare. I suspect your system just uses LVDS; as such there is no link training involved.
I've updated the trace with increased log_buf_len so nothing is truncated:
http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt
(trace now contains a full boot including suspend and wakeup)
However, what I'm seeing now does sound like the internal connection is indeed eDP:
[ 166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0] [ 166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1] [ 166.816167] [drm:drm_crtc_helper_set_config] [ 166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54] #connectors=1 (x y) (0 0) [ 166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [ 166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4) [ 166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [ 166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [ 166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to [CRTC:34:crtc-0] [ 166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [ 166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x0 0x9 [ 166.816180] [drm:radeon_encoder_set_active_device] setting active device to 00000002 from 00000002 00000002 for encoder 3 [ 166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0] [ 166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8 [ 166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices 00000008, active_devices 00000000 [ 166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, devices 00000010, active_devices 00000000 [ 166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.816237] [drm:radeon_compute_pll_avivo] 360000 - 360000, pll dividers - fb: 80.0 ref: 2, post 3 [ 166.824475] done.
Yes it is eDP:
[ 3.197364] [drm] Radeon Display Connectors [ 3.197365] [drm] Connector 0: [ 3.197365] [drm] DP-1 [ 3.197366] [drm] HPD1 [ 3.197367] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 3.197367] [drm] Encoders: [ 3.197368] [drm] DFP1: INTERNAL_UNIPHY [ 3.197369] [drm] Connector 1: [ 3.197369] [drm] eDP-1 [ 3.197370] [drm] HPD2 [ 3.197371] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 3.197371] [drm] Encoders: [ 3.197372] [drm] LCD1: INTERNAL_UNIPHY [ 3.197372] [drm] Connector 2: [ 3.197372] [drm] VGA-1 [ 3.197373] [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c [ 3.197374] [drm] Encoders: [ 3.197374] [drm] CRT2: INTERNAL_KLDSCP_DAC2
... and a bit later:
[ 166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0 pre-emphasis 0 [ 166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0
Yes, the link training appears to complete fine. I guess it's something to do with the proprietary mux or backlight controls.
Alex
Best, Florian
SENT FROM MY DEC VT50 TERMINAL
On 02.06.2017 17:12, Alex Deucher wrote:
On Fri, Jun 2, 2017 at 3:35 AM, Florian Echtler floe@butterbrot.org wrote:
[ 166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0 pre-emphasis 0 [ 166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support [ 166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0
Yes, the link training appears to complete fine. I guess it's something to do with the proprietary mux or backlight controls.
OK, so back to square... well, not one, but definitely back to the registers (SMC and GPU).
As mentioned, the diff for the GPU registers before/after suspend is huge, there's 117 register values that have changed. I assume that most of them are actually internal frame pointers, but which ones? I tried to find some of that information in drivers/gpu/drm/radeon/, but quickly got lost :-/
Regarding the SMC, there's actually only one key that consistently seems to have a different value whether the display is on or off:
--- blank 2017-05-05 08:40:53.694565045 +0200 +++ non_blank 2017-05-05 08:40:53.702565066 +0200 @@ -143,7 +143,7 @@ MSWR [ui8 ] 0 (bytes 00) MVBO [hex_] (bytes ff ff) MVDC [bin_] (bytes 00) - MVDS [bin_] (bytes 08) + MVDS [bin_] (bytes 0a) MVE1 [si8 ] (bytes 0d) MVE5 [si8 ] (bytes 0b) MVHR [flag] (bytes 01)
However, even with my modified SmcDumpKeys.c which I can use to enable TDM, I cannot write to that key. Since other MV__ keys control the display, too, it would make sense that that is related to the display state, but it seems to be a read-only key :-/
Running out of ideas again... any suggestions?
Best, Florian
On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
Regarding the SMC, there's actually only one key that consistently seems to have a different value whether the display is on or off:
--- blank 2017-05-05 08:40:53.694565045 +0200 +++ non_blank 2017-05-05 08:40:53.702565066 +0200 @@ -143,7 +143,7 @@ MSWR [ui8 ] 0 (bytes 00) MVBO [hex_] (bytes ff ff) MVDC [bin_] (bytes 00)
- MVDS [bin_] (bytes 08)
- MVDS [bin_] (bytes 0a) MVE1 [si8 ] (bytes 0d) MVE5 [si8 ] (bytes 0b) MVHR [flag] (bytes 01)
However, even with my modified SmcDumpKeys.c which I can use to enable TDM, I cannot write to that key. Since other MV__ keys control the display, too, it would make sense that that is related to the display state, but it seems to be a read-only key :-/
Running out of ideas again... any suggestions?
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:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Thanks,
Lukas
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:
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).
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.
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.
I'd be grateful about a bit of background information here, I'd really like to help fix this.
Best, Florian
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
On 25.07.2017 07:14, Mario Kleiner wrote:
On 07/24/2017 03:45 PM, Florian Echtler wrote:
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.
OK - I'm guessing if the panel/connector mess gets properly sorted out in general, then it will probably also start working after suspend/resume...
The internal panel always works during boot, until the radeon kms driver loads and modesetting gets initialized, then the panel goes dark.
Weirdly enough, this is now the behaviour I'm getting, too, no matter if I use the patched driver or the original one. So there's definitely some bit of persistent state somewhere that got flipped during experimentation, probably inside that stupid SMC.
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.
None of the video options, either with "DP" or "eDP", made a difference in my case. The one scenario where I suddenly got the internal panel to turn on was when I plugged in a DP _source_ (my laptop). Also caused the same DP link train error messages to appear in dmesg.
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?
Yes, also 27 inch. I've compared the dmidecode output, only notable differences are data from RAM modules, so it's the same machine and same FW versions.
Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.
Nearly everything identical, except my dmesg doesn't show the following lines:
-[ 0.000000] efi: EFI v1.10 by Apple -[ 0.000000] efi: ACPI=0xbfeee000 ACPI 2.0=0xbfeee014 SMBIOS=0xbfec4000
I'm booting Linux via rEFIt, so I would have assumed that it's a "regular" EFI boot, but apparently not. What's your boot configuration?
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?
I'm using TDM regularly; interestingly enough, this works completely reliably, even if the panel was dark before. My code is at https://github.com/floe/smc_util if you want to give it a try, but apparently there's more to it than just the two keys (MVMR/MVHR) which I'm currently using.
Maybe you can run smc_dump_linux.sh on your machine (should be safe, only reads keys) and see if there's some difference between keys depending on what state the panel is in?
Best, Florian
On Tue, Jul 25, 2017 at 07:14:23AM +0200, Mario Kleiner wrote:
On 07/24/2017 03:45 PM, Florian Echtler wrote:
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.
[...]
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?
If all else fails, with a multimeter / oscilloscope. :-) The board schematics are available by googling for the right terms, such as the drawing number "051-7863" and internal codename "K23".
Of interest is the eDP connector on the mainboard, page 90. Notice there are two power rails going into it, 3.3V (pin 31) and 12V (pins 27 - 30). Florian obtained dmesg output of the machine coming out of suspend by ssh'ing into it and it showed that the eDP link could be trained properly upon system resume. Still the panel stayed black.
My guess is that the panel's DisplayPort transceiver is powered via the 3.3V rail. This rail is powered permanently when the system is in S0, it cannot be switched off at runtime. So, the Radeon card can talk to the DisplayPort transceiver (which has power) but the 12V rail, which presumably powers the LED backlight, is off. You could test this theory by attaching a multimeter after coming out of suspend: You should see a voltage difference of 3.3V between pins 31 and 32 (ground) and 0V between pins 27 - 30 and 32.
The logic for the 12V rail is somewhat complicated, first there's pin 21 ("VIDEO_ON"), this seems to come *from* the panel and presumably signals that the link is trained. This should go high after resume. If it does not then maybe a write to a custom DPCD register is necessary to make it go high. If this pin stays low then the 12V rail is not powered.
Next there's a 74LVC157A mux (page 95 top-left). Datasheet: https://assets.nexperia.com/documents/data-sheet/74LVC157A.pdf The mux can switch four wires, but Apple only needed three. I guess all outputs (pins 7, 9, 12) must be high for the backlight to go on. The mux is under the control of the SMC and is presumably switched by issuing appropriate commands to the SMC. It's unclear to me if the SMC has switched it to the Radeon or to the TDM source after resume.
Assuming that the mux is switched to the Radeon card, follow input pins 5, 10 and 14 (MXM_PNL_BL_PWM, MXM_PNL_BL_EN, MXM_PNL_PWR_EN). They are coming from a "system management" block on the Radeon card (pins 25, 27, 23, page 85). Apparently these are GPIO pins for OEM use and I guess they can be controlled by writing to the PCI BAR of the Radeon card, but I've no idea at what address their registers might be located. I'll try to look at the macOS Radeon drivers with a disassembler but this is like looking for a needle in a haystack.
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.
The AUX channel can be terminated in either of two modes under the control of the SMC: 100k source termination or weak sink termination (page 94/95). Failure to communicate over AUX may be explained by being in the incorrect mode.
HTH,
Lukas
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Florian Echtler -
Lukas Wunner -
Mario Kleiner