On 2013-02-06 14:11, Jani Nikula wrote: > On Wed, 06 Feb 2013, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
