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

Reply via email to