Multiple issues with omapdrm

Tomi Valkeinen tomi.valkeinen at ti.com
Wed Jun 5 03:55:25 PDT 2013


On 05/06/13 13:43, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen <tomi.valkeinen at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/677f3ba6/attachment.pgp>


More information about the dri-devel mailing list