iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas at 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