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

Chris Wilson chris at chris-wilson.co.uk
Mon Dec 3 16:12:39 UTC 2018


Quoting Eric Anholt (2018-12-03 16:08:40)
> 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.

I looked as it as being recognition that the stub-fence already exists
on context 0, and so we should reserve that context for private use.
-Chris


More information about the amd-gfx mailing list