Messages in this thread | | | Date | Tue, 22 Jul 2014 17:42:48 +0200 | Subject | Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences | From | Daniel Vetter <> |
| |
On Tue, Jul 22, 2014 at 5:35 PM, Christian König <christian.koenig@amd.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |