Am 10.08.19 um 17:34 schrieb Chris Wilson:
> Allow for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signaling mechanism around every fence.
> (The cost of interrupts is too darn high, to revive an old meme.)
> This means that we may have a cb_list even if the signaling bit is not
> enabled, so always notify the callbacks.
>
> The cost is that dma_fence_signal() must always acquire the spinlock to
> ensure that the cb_list is flushed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/dma-buf/dma-fence.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 027a6a894abd..ab4a456bba04 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -170,11 +170,9 @@ int dma_fence_signal(struct dma_fence *fence)
>
> __dma_fence_signal__timestamp(fence, ktime_get());
>
> - if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) {
> - spin_lock_irqsave(fence->lock, flags);
> - __dma_fence_signal__notify(fence);
> - spin_unlock_irqrestore(fence->lock, flags);
> - }
> + spin_lock_irqsave(fence->lock, flags);
> + __dma_fence_signal__notify(fence);
> + spin_unlock_irqrestore(fence->lock, flags);
If we now always grab the spinlock anyway I suggest to rather merge
dma_fence_signal and dma_fence_signal_locked.
Christian.
> return 0;
> }
> EXPORT_SYMBOL(dma_fence_signal);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
