On Tue, Jul 22, 2014 at 5:35 PM, Christian König <christian.koenig@xxxxxxx> wrote: > Drivers exporting fences need to provide a fence->signaled and a fence->wait > function, everything else like fence->enable_signaling or calling > fence_signaled() from the driver is optional. > > Drivers wanting to use exported fences don't call fence->signaled or > fence->wait in atomic or interrupt context, and not with holding any global > locking primitives (like mmap_sem etc...). Holding locking primitives local > to the driver is ok, as long as they don't conflict with anything possible > used by their own fence implementation. Well that's almost what we have right now with the exception that drivers are allowed (actually must for correctness when updating fences) the ww_mutexes for dma-bufs (or other buffer objects). Locking correctness is enforced with some extremely nasty lockdep annotations + additional debugging infrastructure enabled with CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold dma-buf ww_mutexes while updating fences or waiting for them. And obviously for ->wait we need non-atomic context, not just non-interrupt. Agreed that any shared locks are out of the way (especially stuff like dev->struct_mutex or other non-strictly driver-private stuff, i915 is really bad here still). So from the core fence framework I think we already have exactly this, and we only need to adjust the radeon implementation a bit to make it less risky and invasive to the radeon driver logic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
