[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