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

[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.
-Chris