Dave, I'm about to merge the pre-superioctl branch but I've pushed it for a review first. There are a couple of fixes that shouldn't affect any ongoing super-ioctl work, but then there also is some important changes.
a) A fence error member. The idea is that when we detect a lockup, we signal all fences with fence->error set to non-zero. Then the X server will exit more cleanly if it's also using a superioctl, and we can remove the drm module without too much trouble. b) An interface to map buffer objects from kernel space in whatever memory region they currently reside. drm_bo_kmap / drm_bo_kunmap. Though the ioremap_nocache call might need some tweaking to avoid the cache flushes. c) compat support for PAT write-combining. Buffer objects with the _TTM map type will be mapped PAT write-combined if the processor supports it. Otherwise uncached. We will need this for new hardware that doesn't allow mapping through the aperture, but PAT initializing should be done properly at goot time. Finally a new function to simplify superioctl error paths. The way we currently do it is to validate buffers as usual, but the ioctl "handled" argument is not updated. This means that if we hit an -EAGAIN, the whole validation sequence need to be re-run, which is not a big problem because -EAGAINs are not very common, (typically just mouse movement). Buffers will be placed on the unfenced list, but if we hit an error we just call drm_putback_buffer_objects() that put them back on the lru list, keeping the old fences and without updating the bo->fence_type and bo->fence_class members. If command submission succeeds, we just call drm_fence_buffer_buffer_objects as usual. If this call fails for any reason, we idle the GPU and call drm_putback_buffer_objects(), and return an error to user-space that may do it's own pool fencing. This should be rock solid AFAICT. This makes it possible to use a local "unfenced" list if desired, and should allow us to remove the global one if we feel there is a need. It also avoids creating a fence a validate-time, which is a bit awkward. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
