Messages in this thread | | | Date | Wed, 9 Feb 2011 10:42:05 +0100 (CET) | Subject | Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_ | From | "Indan Zupancic" <> |
| |
On Wed, February 9, 2011 06:45, Jeff Chua wrote: > > This may help a little. I added printk("intel_crtc 2") inside > intel_crtc_reset() and added printk("intel_crtc 1") before calling > intel_crtc_reset(). > > Looking at dmesg, it looks like something else is calling > intel_crtc_reset() and not from intel_crtc_init() during resume.
That something else is the drm layer.
(I must say it's very unclear what the the ordering of driver function calls will be from just looking at drm the code. I hope the drm abstraction is working out well for others, to me it all seems a bit awkward. If state needs to be tracked, fine, but do it either in the drm layer or let the driver handle it.)
> intel_crtc 2 ffff880239cdf000 > intel_crtc 2 ffff880239cdf800
This doesn't really help, all it probably means is that you've got multiple crtc outputs, or something like that. It might help if you get two calls with the offending commit, but only one without it.
I'd add printk's to the *_crtc_disable()/*_crtc_enable() calls with info whether it actually enables or disables something and compare the result between a working suspend and a broken one.
Greetings,
Indan
| |