Re: Multiple hardware locks

[Thomas Hellstr�m]

Jon Smirl wrote: On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. It would probably be better to extend the current driver specific sarea. You can negotiate the driver interface version to enable the new functions. There should be room: #define SAREA_MAX 0x2000 Where is sarea allocated? I looked for five minutes and couldn't find it Hi! The idea of using a separate sarea is that it would be easy to extend the number of locks and more suitable for more drivers than via. Otherwise one idea would be to fill the private sarea from the back, but that would break DDX tests for size of usable area. Different sareas are allocated using drmAddMap with type=DRM_SHM. The one containing the current hardware lock is specified with the flag DRM_CONTAINS_LOCK. /Thomas 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel