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

[Christian König]

Am 03.12.18 um 18:06 schrieb Chris Wilson:
> Quoting Christian König (2018-12-03 16:12:14)
>> 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.
> I would like to be able to reserve 0 for NO_CONTEXT! The stub being but
> one example.

I'm slightly leaning into this direction as well and additional to that 
I've already pushed the patches to drm-misc-next.

The only thing we should avoid is to over use 0 as NO_context, e.g. with 
complicated sequence numbers or similar.

Christian.

> -Chris
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx