[PATCH 1/3] dma-buf: add dma_fence_get_stub

[Eric Anholt]

Christian König <ckoenig.leichtzumerken at gmail.com> writes:

> Am 03.12.18 um 17:08 schrieb Eric Anholt:
>> Christian König <ckoenig.leichtzumerken at gmail.com> writes:
>>
>>> Extract of useful code from the timeline work. This provides a function
>>> to return a stub or dummy fence which is always signaled.
>>>
>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>> ---
>>>   drivers/dma-buf/dma-fence.c | 36 +++++++++++++++++++++++++++++++++++-
>>>   include/linux/dma-fence.h   |  1 +
>>>   2 files changed, 36 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>>> index 1551ca7df394..136ec04d683f 100644
>>> --- a/drivers/dma-buf/dma-fence.c
>>> +++ b/drivers/dma-buf/dma-fence.c
>>>   /*
>>>    * fence context counter: each execution context should have its own
>>>    * fence context, this allows checking if fences belong to the same
>>>    * context or not. One device can have multiple separate contexts,
>>>    * and they're used if some engine can run independently of another.
>>>    */
>>> -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
>>> +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
>> What's this change for?  I don't see a context allocation in patch #2
>> where the stub fence is being moved from, so this seems out of place.
>
> The stub fence is using context 0 and seqno 0, but since it is always 
> signaled this actually shouldn't matter.
>
> So this is just to be on the extra clean side I made sure that nobody 
> else is using context 0.
>
> Alternatively we could also just allocate one when we initialize it for 
> the first time.

I like the allocate at init idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20181203/444e543e/attachment-0001.sig>