Hi, list!
With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock.
The first question is - have you found that lock contention is actually a problem?
I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"?
But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence.
In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip.
My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of.
For many cards, there is a single dma-driven command queue, and the lock is used to protect that queue. All sorts of stuff (video, 2d, 3d) is delivered on the same queue. It sounds like the VIA driver follows a similar single-queue model.
1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence.
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.
But it still sounds like there is a single ring buffer, right? Won't you need a lock to protect the ringbuffer? Won't everything have to grab that lock?
Also, how does direct framebuffer access work? The X server presumably now has to grab all of the locks, and likewise 3d fallbacks, to prevent all access to the framebuffer?
These are just initial thoughts. Is there a mechanism for this in DRM today or could
it be done in a better way?
I guess I'm not sure which problem you're trying to solve. There are a couple I can think of so I'll list them here:
- Lock contention. Under what circumstances?
- Unnecessary flushing of the DMA queue/ringbuffer. IE. If you want to write to/read from a surface in video ram, how do you know when the video card has finished with it?
- Something else?
Keith
------------------------------------------------------- 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_idU88&alloc_id065&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
