Christian König <ckoenig.leichtzumerken@xxxxxxxxx> writes: > Am 03.12.18 um 17:08 schrieb Eric Anholt: >> Christian König <ckoenig.leichtzumerken@xxxxxxxxx> 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@xxxxxxx> >>> --- >>> 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
