[PATCH 1/3] dma-buf: add dma_fence_get_stub
Christian König
ckoenig.leichtzumerken at gmail.com
Mon Dec 3 16:12:14 UTC 2018
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.
Christian.
More information about the dri-devel
mailing list