Mike Mestnik wrote:
--- Thomas Hellström <unichrome@shipmail.org> 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
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

    



		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com