Re: CDF meeting @FOSDEM report

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

On 2013-02-06 14:11, Jani Nikula wrote:
> On Wed, 06 Feb 2013, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> 6. Miscellaneous
>>> ----------------
>>>
>>> - If the OMAP3 DSS driver is used as a model for the DSI support 
>>> implementation, Daniel Vetter requested the DSI bus lock semaphore to be 
>>> killed as it prevents lockdep from working correctly (reference needed ;-)).
> 
> [...]
> 
>> As for the semaphore, sure, it can be removed, although I'm not aware of
>> this lockdep problem. If there's a problem it should be fixed in any case.
> 
> The problem is that lockdep does not support semaphores out of the
> box. I'm not sure how hard it would be to manually lockdep annotate the
> bus lock, and whether it would really work. In any case, as I think we
> learned in the past, getting locking right in a DSI command mode panel
> driver with an asynchronous update callback, DSI bus lock, and a driver
> data specific mutex can be a PITA. Lockdep would be extremely useful
> there.
> 
> AFAICS simply replacing the semaphore with a mutex would work for all
> other cases except DSI command mode display update, unless you're
> prepared to wait in the call until the next tearing effect interrupt
> plus framedone. Which would suck. I think you and I have talked about
> this part in the past...

Mutex requires locking and unlocking to happen from the same thread. But
I guess that's what you meant that the problem would be with display
update, where the framedone callback is used to release the bus lock.

The semaphore could probably be changed to use wait queues, but isn't
that more or less what a semaphore already does?

And I want to point out to those not familiar with omapdss, that the DSI
bus lock in question does not protect any data in memory, but is an
indication that the DSI bus is currently in use. The bus lock can be
used to wait until the bus is free again.

I guess one option would be to disallow any waiting for the bus lock. If
the panel driver would try acquire bus lock, and the lock is already
taken, the call would fail. This would move the handling of exclusivity
to the user of the panel (drm driver, I guess), which already should
handle the framedone event.

The above would require that everything the panel does should be managed
by the drm driver. Currently this is not the case for OMAP, as the panel
driver can get calls via sysfs, or via backlight driver, or via (gpio)
interrupts.

I don't really know what would be the best option here. On one hand
requiring all panel calls to be managed by drm would be nice and simple.
But it is a bit limiting when thinking about complex display chips. Will
that work for all cases? I'm not sure.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 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