On 05/06/13 13:43, Rob Clark wrote: > On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
