On 05/06/13 13:43, Rob Clark wrote:
On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
I did some testing with omapdrm on v3.10-rc1. Here are some issues I encountered. For most of them I don't have any idea where to even start looking for a problem, so I hope that you may have some ideas.
dispc_runtime_get/put used in irq context
dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack around that with if (!in_atomic()), but I have no idea yet how to fix it properly.
Probably should have a flag/refcnt that is set when in the irq hander, since we know that things are on in irq.
Maybe.
However, I'd like more an approach where the dispc registers are only programmed when a display is enabled. If the display in question is disabled, no registers would be written.
I think that would also support losing DISPC register context. The DISPC driver currently stores all its registers when the pm_runtime refcount goes to 0, and restores them on pm_runtime_get. That's a bit heavy, and uses the OMAP specific ctx-loss-count support, which should be removed (and if that's removed, the register save/restore becomes even heavier).
Things would be simpler if omapdrm (and omapfb) knows how to program all the relevant registers when a display is enabled, and keeps the necessary state stored in memory (including irq settings).
somewhere in the cleanup it should do a put_paddr(). Otoh, I have some skepticism about whether module unloading is really going to be that reliable in practice, so meh..
Why is that?
Tomi