On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
