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

[Daniel Vetter]

On Wed, Jul 23, 2014 at 2:36 PM, Christian KÃnig
<christian.koenig@xxxxxxx> wrote:
> My idea was more that the fence framework provides a
> fence->process_signaling callback that is periodically called after
> enable_signaling is called to trigger manual signal processing in the
> driver.
>
> This would both be suitable as a fallback in case of not working interrupts
> as well as a chance for any driver to do necessary lockup handling.

Imo that should be an implementation detail of the fence provider. So
in ->enable_signaling radeon needs to arm a delayed work to regularly
check fence and signal them if the irq failed. If it's a common need
we might provide some shared code for this (e.g. a struct
unreliable_fence or so). But this shouldn't be mandatory since not all
gpus are broken like that.

And if we force other drivers to care for this special case that imo
leaks the abstraction out of radeon (or any other driver with
unreliable interrupts).
-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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/