Dave Airlie wrote: >>> >>> >> Yes, I think so. One reason to lock is to make sure the GTT page table >> is really repopulated after a resume, but that can be handled in the DRM >> driver resume function, and we could perhaps >> change the user-space lock_mm() to ignore kernel_bos. >> > > It defintely should all be handled in-kernel, putting functionality like > that under user space control is a throw back, the lock-mm should maybe > only apply to the bos allocated to that user who locks.. or really I'm not > sure we really need a lock function if we have a proper kernel driver.. > > I'm not sure that we need that either. Currently it has two purposes:
1) Make sure the X server doesn't use any VRAM or TT resources when it's VT switched. With TTM I don't think we really need this, since if an fb app or whatever needs space, it will evict the X server and DRI buffers. 2) Make dri clients sleep while VT is switched away. If we decide that 1) is not important with kernel-created mms, the problem more or less goes away, and I haven't really read up enough on the new drm design to know how 2 is supposed to be handled. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
