Mike Mestnik wrote:
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
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. 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"?
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.
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
There is a problem with A "client" being able to lock/unlock resources it
may/may not be using. It's important that Client's arn't able to DOS the
system by submitting junk cmds /wo setting the right locs for that junk.
Such a case would be a client submitting 2D engine commands while the X
server waits for 2D engine idle. Either this has to be implemented in
the command verifier or considered acceptable behaviour. Today any dri
client can continously clear the screen without taking the hardware
lock.
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
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com
|
