> 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.
It looks good to me, I'm just starting on making a 915 superioctl cleanly using BOs to store the relocations so I'll base it off this branch.. Dave. ------------------------------------------------------------------------- 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
