Re: Multiple issues with omapdrm

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Multiple issues with omapdrm
Date: Wed, 5 Jun 2013 13:55:25 +0300	[thread overview]
Message-ID: <51AF191D.8090108@ti.com> (raw)
In-Reply-To: <CAF6AEGt_hyuwrKKkV4=nsPbtY1=OAuY9GkiMTEZRfhN_CzcfhQ@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel