[PATCH 09/11] dma-buf: add shared fence usage flags

[Christian König]

Am 17.05.21 um 22:36 schrieb Daniel Vetter:
> On Mon, May 17, 2021 at 04:11:27PM +0200, Christian König wrote:
>> Add usage flags for shared fences and improve the documentation.
>>
>> This allows driver to better specify what shared fences
>> are doing with the resource.
>>
>> Signed-off-by: Christian König <christian.koenig at amd.com>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 16b869d9b1d6..c9bbc4630afc 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -700,7 +700,7 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
>>   		return ret;
>>   	}
>>   
>> -	dma_resv_add_shared_fence(bo->base.resv, fence);
>> +	dma_resv_add_shared(bo->base.resv, fence, DMA_RESV_USAGE_RW);
> Entirely aside, but I ended up scratching my head a lot for why exactly
> this here is a shared fence, and why that's ok. Since just looking at this
> it seems like waiting for the memory allocation to actually be owned by
> this driver is optional.
>
> Is this ok because the next thing we'll do is a move, which will then set
> the exclusive fence here. Which will then wait on the shared one here, so
> it doesn't matter? Or well, allows us to pipeline the eviction of ttm_man
> against whatever might be currently keeping the bo busy in it's current
> place?

Yes, exactly that.

We just need to make sure that the new BO location isn't used before the 
fence is completed, but we can't use the exclusive slot because we have 
no guarantee at all that the move fence signals in the right order.

Regards,
Christian.

>
> Might be good candidate to explain this in a comment or something like
> that.
> -Daniel