From: Jerome G. <gl...@fr...> - 2008-08-26 15:56:27
|
On Tue, 26 Aug 2008 11:43:03 +0200 Thomas Hellström <th...@tu...> wrote: > Dave, > This all sounds good. > > The drm_bo_lock.c is intended to replace the drm hardware lock on VT > switches when the X server wants to clean > all memory for release to a legacy fbdev driver. It will block all drm > clients trying to put a buffer in video memory, and > basically stall them until the X server is switched back in, in which > case the X server will: > > 1) release the bo_lock allowing for clients to start rendering to > private buffers. > b) allocate and set up its new front buffer > c) release the DRM hardware lock, allowing for clients to access the > SAREA and thus the new front buffer. > > I'm not sure how this fits into the modesetting world. Perhaps the need > for it will go away, but for largely lockless > legacy DRI solutions (where the lock only protects the SAREA) it's needed. > > /Thomas In KMS world this is useless but if we want to expose memory manager without KMS then this might be handy and we could avoid the hack of reserving the begining of vram on avivo hw to save VGA stuff. I will try to find sometimes to go through the code. Cheers, Jerome Glisse <gl...@fr...> |