[Bug 98832] Distorted colours after suspend / resume cycle

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98832

--- Comment #8 from Jan-Marek Glogowski <glogow at fbihome.de> ---
Seems I actually forgot to post my last comment…

So I added various versions of:

printk(KERN_ALERT "JMG - %s:%d: ...\n", __FUNCTION__, __LINE__, ....);

And it seems the problem occurs less often now, which is adding to my suspicion
of a race condition, as DPMS wake-up doesn't always show broken colours.

I couldn't really identify a place with a missing radeon_crtc_load_lut

[Mo Dez  5 16:10:43 2016] JMG - dce5_crtc_load_lut:108: 0
[Mo Dez  5 16:12:56 2016] JMG - atombios_crtc_dpms:294: 3 (off)
[Mo Dez  5 16:12:56 2016] JMG - atombios_crtc_dpms:294: 1 (standby)
[Mo Dez  5 16:13:56 2016] JMG - atombios_crtc_dpms:294: 2 (suspend)
[Mo Dez  5 16:14:56 2016] JMG - atombios_crtc_dpms:294: 3 (off)
[Mo Dez  5 16:45:52 2016] JMG - atombios_crtc_dpms:294: 0 (on)
[Mo Dez  5 16:45:52 2016] JMG - radeon_crtc_load_lut:196: 1
[Mo Dez  5 16:45:52 2016] JMG - dce5_crtc_load_lut:108: 0

This was definitely calling dce5_crtc_load_lut, but nevertheless the colours
were wrong.
I'm not sure why "atombios_crtc_dpms:294: 3" is called twice, probably also for
the inactive port?

I couldn't reproduce by just waiting for 5 minutes or setting radeon.dpm=0.

So we did a rollout for my few test machines a few days ago with disabled dpm.
Currently the feedback is positive, so we're planing to do the rollout to our
few thousand machines next year.

I'm not caring that much about the suspend / resume, but the broken colours
after DPMS (so no suspend involved) are highly irritating for the users.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20161222/f559cd0c/attachment.html>