On Thursday, November 24, 2005 4:50 am, Thomas Hellström wrote: > There is some info in the old precision insight documentation about > the DRI infrastructure, (can't seem to find a link right now) But > generally there is only one global lock and something called the > drawable spinlock that is apparently not used anymore. The global > lock is similar to a futex, with the exception that the kernel is > called both to resolve contention and whenever a new context is about > to take the lock, so that optional context switching can take place, > and also if the client requests that some special action should take > place after locking is done, like wait for dma ready or quiescent. > The lock should be taken before writing to the hardware or before > submitting DMA commands. If you want to be _sure_ that noone else > uses the hardware (like you want to read a particular register or > something), you have to take the lock and wait for DMA quiescent. For > example, if you want to make sure the video scaler is idle so you can > write to it, you first take the lock so that noone else writes to it > or to the DMA queue, then you wait for the DMA queue to be empty or > make sure there are no pending commands for the scaler, then you wait > for the scaler to become idle. > > The lock value is easily manipulated from user space and resides in > one of the shared memory areas. I guess this means that with the > current drm security policy it should be regarded as an advisory lock > between drm clients.
This is a nice little writeup, maybe it could go into the kernel's Documentation/ directory? It would be nice to document how the lock and signal handling interact as well. > At one point I was about to implement a scheme for via with a number > of similar locks, one for each independent function on the video > chip, Like 2D, 3D, Mpeg decoder, Video scaler 1 and 2, so that they > didn't have to wait for eachother. The global lock would then only > be taken to make sure that no drawables were touched by the X server > or other clients while the lock was held, which would be compatible > with how the X server works today. Never got around to do that, > however, but the mpeg decoders have a futex scheme to prevent clients > stepping on eachother. With that it is possible to have multiple > clients use the same hw decoder. Sounds interesting, but that would be card specific, right? I mean, on some cards the 2d and 3d locks would have to be the same because of shared state or whatever, for example. Jesse ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
