Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_

[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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/