| Message ID | 20181203130759.10226-1-christian.koenig@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] dma-buf: add dma_fence_get_stub | expand |
The series is Reviewed-by: Chunming Zhou <david1.zhou@amd.com> for patch#2, please remove my Signed-off-by, it's new when using stub from dma-fence. -David 在 2018/12/3 21:07, Christian König 写道: > 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@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 > @@ -30,13 +30,16 @@ > EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > > +static DEFINE_SPINLOCK(dma_fence_stub_lock); > +static struct dma_fence dma_fence_stub; > + > /* > * 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); > > /** > * DOC: DMA fences overview > @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); > * &dma_buf.resv pointer. > */ > > +static const char *dma_fence_stub_get_name(struct dma_fence *fence) > +{ > + return "stub"; > +} > + > +static const struct dma_fence_ops dma_fence_stub_ops = { > + .get_driver_name = dma_fence_stub_get_name, > + .get_timeline_name = dma_fence_stub_get_name, > +}; > + > +/** > + * dma_fence_get_stub - return a signaled fence > + * > + * Return a stub fence which is already signaled. > + */ > +struct dma_fence *dma_fence_get_stub(void) > +{ > + spin_lock(&dma_fence_stub_lock); > + if (!dma_fence_stub.ops) { > + dma_fence_init(&dma_fence_stub, > + &dma_fence_stub_ops, > + &dma_fence_stub_lock, > + 0, 0); > + dma_fence_signal_locked(&dma_fence_stub); > + } > + spin_unlock(&dma_fence_stub_lock); > + > + return dma_fence_get(&dma_fence_stub); > +} > +EXPORT_SYMBOL(dma_fence_get_stub); > + > /** > * dma_fence_context_alloc - allocate an array of fence contexts > * @num: amount of contexts to allocate > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index 02dba8cd033d..999e4b104410 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr) > return ret < 0 ? ret : 0; > } > > +struct dma_fence *dma_fence_get_stub(void); > u64 dma_fence_context_alloc(unsigned num); > > #define DMA_FENCE_TRACE(f, fmt, args...) \
Am 03.12.18 um 14:33 schrieb Chunming Zhou: > The series is Reviewed-by: Chunming Zhou <david1.zhou@amd.com> > > for patch#2, please remove my Signed-off-by, it's new when using stub > from dma-fence. Yeah, ok. There is indeed nothing left from your original code. Alex, Daniel, Chris any objections that I push the first two patches in this series to drm-misc-next? Shouldn't be any functional change, Christian. > > > -David > > > 在 2018/12/3 21:07, Christian König 写道: >> 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@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 >> @@ -30,13 +30,16 @@ >> EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); >> EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); >> >> +static DEFINE_SPINLOCK(dma_fence_stub_lock); >> +static struct dma_fence dma_fence_stub; >> + >> /* >> * 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); >> >> /** >> * DOC: DMA fences overview >> @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); >> * &dma_buf.resv pointer. >> */ >> >> +static const char *dma_fence_stub_get_name(struct dma_fence *fence) >> +{ >> + return "stub"; >> +} >> + >> +static const struct dma_fence_ops dma_fence_stub_ops = { >> + .get_driver_name = dma_fence_stub_get_name, >> + .get_timeline_name = dma_fence_stub_get_name, >> +}; >> + >> +/** >> + * dma_fence_get_stub - return a signaled fence >> + * >> + * Return a stub fence which is already signaled. >> + */ >> +struct dma_fence *dma_fence_get_stub(void) >> +{ >> + spin_lock(&dma_fence_stub_lock); >> + if (!dma_fence_stub.ops) { >> + dma_fence_init(&dma_fence_stub, >> + &dma_fence_stub_ops, >> + &dma_fence_stub_lock, >> + 0, 0); >> + dma_fence_signal_locked(&dma_fence_stub); >> + } >> + spin_unlock(&dma_fence_stub_lock); >> + >> + return dma_fence_get(&dma_fence_stub); >> +} >> +EXPORT_SYMBOL(dma_fence_get_stub); >> + >> /** >> * dma_fence_context_alloc - allocate an array of fence contexts >> * @num: amount of contexts to allocate >> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h >> index 02dba8cd033d..999e4b104410 100644 >> --- a/include/linux/dma-fence.h >> +++ b/include/linux/dma-fence.h >> @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr) >> return ret < 0 ? ret : 0; >> } >> >> +struct dma_fence *dma_fence_get_stub(void); >> u64 dma_fence_context_alloc(unsigned num); >> >> #define DMA_FENCE_TRACE(f, fmt, args...) \ > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Dec 3, 2018 at 8:40 AM Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Am 03.12.18 um 14:33 schrieb Chunming Zhou: > > The series is Reviewed-by: Chunming Zhou <david1.zhou@amd.com> > > > > for patch#2, please remove my Signed-off-by, it's new when using stub > > from dma-fence. > > Yeah, ok. There is indeed nothing left from your original code. > > Alex, Daniel, Chris any objections that I push the first two patches in > this series to drm-misc-next? No objections from me. Does Intel want to run it through their CI? Alex > > Shouldn't be any functional change, > Christian. > > > > > > > -David > > > > > > 在 2018/12/3 21:07, Christian König 写道: > >> 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@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 > >> @@ -30,13 +30,16 @@ > >> EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > >> EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > >> > >> +static DEFINE_SPINLOCK(dma_fence_stub_lock); > >> +static struct dma_fence dma_fence_stub; > >> + > >> /* > >> * 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); > >> > >> /** > >> * DOC: DMA fences overview > >> @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); > >> * &dma_buf.resv pointer. > >> */ > >> > >> +static const char *dma_fence_stub_get_name(struct dma_fence *fence) > >> +{ > >> + return "stub"; > >> +} > >> + > >> +static const struct dma_fence_ops dma_fence_stub_ops = { > >> + .get_driver_name = dma_fence_stub_get_name, > >> + .get_timeline_name = dma_fence_stub_get_name, > >> +}; > >> + > >> +/** > >> + * dma_fence_get_stub - return a signaled fence > >> + * > >> + * Return a stub fence which is already signaled. > >> + */ > >> +struct dma_fence *dma_fence_get_stub(void) > >> +{ > >> + spin_lock(&dma_fence_stub_lock); > >> + if (!dma_fence_stub.ops) { > >> + dma_fence_init(&dma_fence_stub, > >> + &dma_fence_stub_ops, > >> + &dma_fence_stub_lock, > >> + 0, 0); > >> + dma_fence_signal_locked(&dma_fence_stub); > >> + } > >> + spin_unlock(&dma_fence_stub_lock); > >> + > >> + return dma_fence_get(&dma_fence_stub); > >> +} > >> +EXPORT_SYMBOL(dma_fence_get_stub); > >> + > >> /** > >> * dma_fence_context_alloc - allocate an array of fence contexts > >> * @num: amount of contexts to allocate > >> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > >> index 02dba8cd033d..999e4b104410 100644 > >> --- a/include/linux/dma-fence.h > >> +++ b/include/linux/dma-fence.h > >> @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr) > >> return ret < 0 ? ret : 0; > >> } > >> > >> +struct dma_fence *dma_fence_get_stub(void); > >> u64 dma_fence_context_alloc(unsigned num); > >> > >> #define DMA_FENCE_TRACE(f, fmt, args...) \ > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Christian König (2018-12-03 13:07:57) > 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@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
Quoting Alex Deucher (2018-12-03 15:53:21) > On Mon, Dec 3, 2018 at 8:40 AM Christian König > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > Am 03.12.18 um 14:33 schrieb Chunming Zhou: > > > The series is Reviewed-by: Chunming Zhou <david1.zhou@amd.com> > > > > > > for patch#2, please remove my Signed-off-by, it's new when using stub > > > from dma-fence. > > > > Yeah, ok. There is indeed nothing left from your original code. > > > > Alex, Daniel, Chris any objections that I push the first two patches in > > this series to drm-misc-next? > > No objections from me. Does Intel want to run it through their CI? Gut feeling says we have no test coverage for SYNCOBJ_CREATE_SIGNALED. -Chris
Christian König <ckoenig.leichtzumerken@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@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.
Am 03.12.18 um 17:08 schrieb Eric Anholt: > Christian König <ckoenig.leichtzumerken@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@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.
Quoting Eric Anholt (2018-12-03 16:08:40) > Christian König <ckoenig.leichtzumerken@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@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
Christian König <ckoenig.leichtzumerken@gmail.com> writes: > Am 03.12.18 um 17:08 schrieb Eric Anholt: >> Christian König <ckoenig.leichtzumerken@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@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. I like the allocate at init idea.
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@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@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
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@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@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
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 @@ -30,13 +30,16 @@ EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); +static DEFINE_SPINLOCK(dma_fence_stub_lock); +static struct dma_fence dma_fence_stub; + /* * 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); /** * DOC: DMA fences overview @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); * &dma_buf.resv pointer. */ +static const char *dma_fence_stub_get_name(struct dma_fence *fence) +{ + return "stub"; +} + +static const struct dma_fence_ops dma_fence_stub_ops = { + .get_driver_name = dma_fence_stub_get_name, + .get_timeline_name = dma_fence_stub_get_name, +}; + +/** + * dma_fence_get_stub - return a signaled fence + * + * Return a stub fence which is already signaled. + */ +struct dma_fence *dma_fence_get_stub(void) +{ + spin_lock(&dma_fence_stub_lock); + if (!dma_fence_stub.ops) { + dma_fence_init(&dma_fence_stub, + &dma_fence_stub_ops, + &dma_fence_stub_lock, + 0, 0); + dma_fence_signal_locked(&dma_fence_stub); + } + spin_unlock(&dma_fence_stub_lock); + + return dma_fence_get(&dma_fence_stub); +} +EXPORT_SYMBOL(dma_fence_get_stub); + /** * dma_fence_context_alloc - allocate an array of fence contexts * @num: amount of contexts to allocate diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 02dba8cd033d..999e4b104410 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr) return ret < 0 ? ret : 0; } +struct dma_fence *dma_fence_get_stub(void); u64 dma_fence_context_alloc(unsigned num); #define DMA_FENCE_TRACE(f, fmt, args...) \
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@amd.com> --- drivers/dma-buf/dma-fence.c | 36 +++++++++++++++++++++++++++++++++++- include/linux/dma-fence.h | 1 + 2 files changed, 36 insertions(+), 1 deletion(-)