[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

[Daniel Vetter]

On Tue, Jul 22, 2014 at 5:35 PM, Christian König
<christian.koenig at 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