Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
Am 03.04.22 um 00:16 schrieb Bas Nieuwenhuizen:
On Mon, Mar 21, 2022 at 2:59 PM Christian König
wrote:
[SNIP]
@@ -519,17 +513,17 @@ EXPORT_SYMBOL_GPL(dma_resv_iter_first);
*/
struct dma_fence *dma_resv_iter_next(struct dma_resv_iter *cursor)
{
- unsigned int idx;
+ struct dma_fence *fence;
dma_resv_assert_held(cursor->obj);
cursor->is_restarted = false;
- if (!cursor->fences || cursor->index >= cursor->fences->shared_count)
+ if (!cursor->fences || cursor->index >= cursor->fences->num_fences)
return NULL;
- idx = cursor->index++;
- return rcu_dereference_protected(cursor->fences->shared[idx],
-dma_resv_held(cursor->obj));
+ dma_resv_list_entry(cursor->fences, cursor->index++,
+ cursor->obj, , >fence_usage);
Shouldn't we skip the current fence if cursor->fence_usage doesn't
match cursor->usage ? (similar to what is done wrt the unlocked
variant)
Oh, good point. Totally missed that.
Thanks,
Christian.
Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
On Mon, Mar 21, 2022 at 2:59 PM Christian König
wrote:
>
> Instead of distingting between shared and exclusive fences specify
> the fence usage while adding fences.
>
> Rework all drivers to use this interface instead and deprecate the old one.
>
> v2: some kerneldoc comments suggested by Daniel
> v3: fix a missing case in radeon
> v4: rebase on nouveau changes, fix lockdep and temporary disable warning
> v5: more documentation updates
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c| 345 --
> drivers/dma-buf/st-dma-resv.c | 101 ++---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 10 +-
> drivers/gpu/drm/i915/gem/i915_gem_busy.c | 13 +-
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +-
> drivers/gpu/drm/i915/i915_vma.c | 6 +-
> drivers/gpu/drm/lima/lima_gem.c | 2 +-
> drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +-
> drivers/gpu/drm/nouveau/nouveau_fence.c | 4 +-
> drivers/gpu/drm/qxl/qxl_release.c | 3 +-
> drivers/gpu/drm/radeon/radeon_object.c| 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +-
> drivers/gpu/drm/ttm/ttm_execbuf_util.c| 6 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 4 +-
> drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
> drivers/gpu/drm/vgem/vgem_fence.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 3 +-
> include/linux/dma-buf.h | 17 +-
> include/linux/dma-resv.h | 72 ++--
> 26 files changed, 276 insertions(+), 370 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index bb7b023c2d33..26257ba1527e 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -44,12 +44,12 @@
> /**
> * DOC: Reservation Object Overview
> *
> - * The reservation object provides a mechanism to manage shared and
> - * exclusive fences associated with a buffer. A reservation object
> - * can have attached one exclusive fence (normally associated with
> - * write operations) or N shared fences (read operations). The RCU
> - * mechanism is used to protect read access to fences from locked
> - * write-side updates.
> + * The reservation object provides a mechanism to manage a container of
> + * dma_fence object associated with a resource. A reservation object
> + * can have any number of fences attaches to it. Each fence carring an usage
> + * parameter determining how the operation represented by the fence is using
> the
> + * resource. The RCU mechanism is used to protect read access to fences from
> + * locked write-side updates.
> *
> * See struct dma_resv for more details.
> */
> @@ -57,29 +57,74 @@
> DEFINE_WD_CLASS(reservation_ww_class);
> EXPORT_SYMBOL(reservation_ww_class);
>
> +/* Mask for the lower fence pointer bits */
> +#define DMA_RESV_LIST_MASK 0x3
> +
> struct dma_resv_list {
> struct rcu_head rcu;
> - u32 shared_count, shared_max;
> - struct dma_fence __rcu *shared[];
> + u32 num_fences, max_fences;
> + struct dma_fence __rcu *table[];
> };
>
> +/**
> + * dma_resv_list_entry - extract fence and usage from a list entry
> + * @list: the list to extract and entry from
> + * @index: which entry we want
> + * @resv: optional dma_resv obj for lockdep check that the access is allowed
> + * @fence: the resulting fence
> + * @usage: the resulting usage
> + *
> + * Extract the fence and usage flags from an RCU protected entry in the list.
> + */
> +static void dma_resv_list_entry(struct dma_resv_list *list, unsigned int
> index,
> + struct dma_resv *resv, struct dma_fence
> **fence,
> + enum dma_resv_usage *usage)
> +{
> + long tmp;
> +
> + tmp = (long)rcu_dereference_check(list->table[index],
> + resv ? dma_resv_held(resv) : true);
> + *fence = (struct dma_fence *)(tmp & ~DMA_RESV_LIST_MASK);
> + if (usage)
> + *usage = tmp & DMA_RESV_LIST_MASK;
> +}
> +
> +/**
> + * dma_resv_list_set - set fence and usage at a specific index
> + * @list: the list to modify
> + * @index: where to make the change
> + * @fence: the fence to set
> + * @usage: the usage to set
> + *
> + * Set the fence and usage flags at the specific index in the list.
> + */
> +static void dma_resv_list_set(struct dma_resv_list *list,
> + unsigned int index,
> +
Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
On Fri, Apr 01, 2022 at 05:01:13PM +0200, Christian König wrote:
>
>
> Am 29.03.22 um 17:43 schrieb Daniel Vetter:
> > On Mon, Mar 21, 2022 at 02:58:50PM +0100, Christian König wrote:
> > [SNIP]
> > > /**
> > > - * dma_resv_add_shared_fence - Add a fence to a shared slot
> > > + * dma_resv_add_fence - Add a fence to the dma_resv obj
> > >* @obj: the reservation object
> > > - * @fence: the shared fence to add
> > > + * @fence: the fence to add
> > > + * @usage: how the fence is used, see enum dma_resv_usage
> > >*
> > > - * Add a fence to a shared slot, @obj must be locked with
> > > dma_resv_lock(), and
> > > + * Add a fence to a slot, @obj must be locked with dma_resv_lock(), and
> > >* dma_resv_reserve_fences() has been called.
> > >*
> > >* See also _resv.fence for a discussion of the semantics.
> > >*/
> > > -void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence
> > > *fence)
> > > +void dma_resv_add_fence(struct dma_resv *obj, struct dma_fence *fence,
> > > + enum dma_resv_usage usage)
> > > {
> > > struct dma_resv_list *fobj;
> > > struct dma_fence *old;
> > > @@ -274,44 +308,45 @@ void dma_resv_add_shared_fence(struct dma_resv
> > > *obj, struct dma_fence *fence)
> > > dma_resv_assert_held(obj);
> > > - /* Drivers should not add containers here, instead add each fence
> > > - * individually.
> > > + /* TODO: Drivers should not add containers here, instead add each fence
> > > + * individually. Disabled for now until we cleaned up amdgpu/ttm.
> > >*/
> > > - WARN_ON(dma_fence_is_container(fence));
> > > + /* WARN_ON(dma_fence_is_container(fence)); */
> > Uh this looks like it's a misplaced hack?
>
> Unfortunately not.
>
> > If you do need it and cant get rid of it with patch reordering, then I
> > think it needs to be split out for extra attention.
>
> The problem is that I would need to squash removing the amdgpu workaround
> into this patch as well.
>
> And I don't really want to make this patch more complicated that it already
> is.
Yeah I got it later on. Please explain the story in the commit message,
and how it'll be resolved. Otherwise this is a bit much wtf to merge :-)
>
> > > diff --git a/drivers/gpu/drm/lima/lima_gem.c
> > > b/drivers/gpu/drm/lima/lima_gem.c
> > > index 9435a3ca71c8..38caa7f78871 100644
> > > --- a/drivers/gpu/drm/lima/lima_gem.c
> > > +++ b/drivers/gpu/drm/lima/lima_gem.c
> > > @@ -366,7 +366,7 @@ int lima_gem_submit(struct drm_file *file, struct
> > > lima_submit *submit)
> > > if (submit->bos[i].flags & LIMA_SUBMIT_BO_WRITE)
> > > dma_resv_add_excl_fence(lima_bo_resv(bos[i]),
> > > fence);
> > Not very compile-tested it seems.
>
> At least it used to compile fine once, but obviously need to give it another
> go.
>
> > I think it'd be good to split this further:
> >
> > - Add dma_resv_add_fence, which just adds either an exclusive or shared
> >fences.
> > - Convert drivers, cc driver authors (this patch doesn't seem to have
> >them).
> >
> > I think the above two could also be a single patch, but should work even
> > more split.
>
> That is easier said than done. I will see what I can do.
>
> The other documentation comments you had should be fixed in the next round,
> but you might want to take another full look at this.
Yeah I get that it's utter pain. I think if you add a list to the commit
message with a few comments on how each driver is touched and all that
(i.e. at least type up the separate commmit messages for the separate
patches that should be split, but are a real pain to split), then I think
that's fine.
I've also done audit patches in the past which had that per-driver blurb
to cover all the cases, sometimes that's the least crappy way to do
things.
Holds also for the other patches which then add USAGE_KERNEL and
USAGE_BOOKKEEPING - splitting is a bit much but at least having a
per-driver blurb of what/why you change would be really good to include I
think. Just so we remember a bit easier why things changed. I think then
we should be good here with these (well aside from the one ttm change that
I didn't follow yet in another patch).
-Daniel
>
> Thanks,
> Christian.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
Am 29.03.22 um 17:43 schrieb Daniel Vetter:
On Mon, Mar 21, 2022 at 02:58:50PM +0100, Christian König wrote:
[SNIP]
/**
- * dma_resv_add_shared_fence - Add a fence to a shared slot
+ * dma_resv_add_fence - Add a fence to the dma_resv obj
* @obj: the reservation object
- * @fence: the shared fence to add
+ * @fence: the fence to add
+ * @usage: how the fence is used, see enum dma_resv_usage
*
- * Add a fence to a shared slot, @obj must be locked with dma_resv_lock(), and
+ * Add a fence to a slot, @obj must be locked with dma_resv_lock(), and
* dma_resv_reserve_fences() has been called.
*
* See also _resv.fence for a discussion of the semantics.
*/
-void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence)
+void dma_resv_add_fence(struct dma_resv *obj, struct dma_fence *fence,
+ enum dma_resv_usage usage)
{
struct dma_resv_list *fobj;
struct dma_fence *old;
@@ -274,44 +308,45 @@ void dma_resv_add_shared_fence(struct dma_resv *obj,
struct dma_fence *fence)
dma_resv_assert_held(obj);
- /* Drivers should not add containers here, instead add each fence
-* individually.
+ /* TODO: Drivers should not add containers here, instead add each fence
+* individually. Disabled for now until we cleaned up amdgpu/ttm.
*/
- WARN_ON(dma_fence_is_container(fence));
+ /* WARN_ON(dma_fence_is_container(fence)); */
Uh this looks like it's a misplaced hack?
Unfortunately not.
If you do need it and cant get rid of it with patch reordering, then I
think it needs to be split out for extra attention.
The problem is that I would need to squash removing the amdgpu
workaround into this patch as well.
And I don't really want to make this patch more complicated that it
already is.
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 9435a3ca71c8..38caa7f78871 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -366,7 +366,7 @@ int lima_gem_submit(struct drm_file *file, struct
lima_submit *submit)
if (submit->bos[i].flags & LIMA_SUBMIT_BO_WRITE)
dma_resv_add_excl_fence(lima_bo_resv(bos[i]), fence);
Not very compile-tested it seems.
At least it used to compile fine once, but obviously need to give it
another go.
I think it'd be good to split this further:
- Add dma_resv_add_fence, which just adds either an exclusive or shared
fences.
- Convert drivers, cc driver authors (this patch doesn't seem to have
them).
I think the above two could also be a single patch, but should work even
more split.
That is easier said than done. I will see what I can do.
The other documentation comments you had should be fixed in the next
round, but you might want to take another full look at this.
Thanks,
Christian.
Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
On Mon, Mar 21, 2022 at 02:58:50PM +0100, Christian König wrote:
> Instead of distingting between shared and exclusive fences specify
> the fence usage while adding fences.
>
> Rework all drivers to use this interface instead and deprecate the old one.
>
> v2: some kerneldoc comments suggested by Daniel
> v3: fix a missing case in radeon
> v4: rebase on nouveau changes, fix lockdep and temporary disable warning
> v5: more documentation updates
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c| 345 --
> drivers/dma-buf/st-dma-resv.c | 101 ++---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 10 +-
> drivers/gpu/drm/i915/gem/i915_gem_busy.c | 13 +-
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +-
> drivers/gpu/drm/i915/i915_vma.c | 6 +-
> drivers/gpu/drm/lima/lima_gem.c | 2 +-
> drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +-
> drivers/gpu/drm/nouveau/nouveau_fence.c | 4 +-
> drivers/gpu/drm/qxl/qxl_release.c | 3 +-
> drivers/gpu/drm/radeon/radeon_object.c| 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +-
> drivers/gpu/drm/ttm/ttm_execbuf_util.c| 6 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 4 +-
> drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
> drivers/gpu/drm/vgem/vgem_fence.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 3 +-
> include/linux/dma-buf.h | 17 +-
> include/linux/dma-resv.h | 72 ++--
> 26 files changed, 276 insertions(+), 370 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index bb7b023c2d33..26257ba1527e 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -44,12 +44,12 @@
> /**
> * DOC: Reservation Object Overview
> *
> - * The reservation object provides a mechanism to manage shared and
> - * exclusive fences associated with a buffer. A reservation object
> - * can have attached one exclusive fence (normally associated with
> - * write operations) or N shared fences (read operations). The RCU
> - * mechanism is used to protect read access to fences from locked
> - * write-side updates.
> + * The reservation object provides a mechanism to manage a container of
> + * dma_fence object associated with a resource. A reservation object
> + * can have any number of fences attaches to it. Each fence carring an usage
carries
> + * parameter determining how the operation represented by the fence is using
> the
> + * resource. The RCU mechanism is used to protect read access to fences from
> + * locked write-side updates.
> *
> * See struct dma_resv for more details.
> */
> @@ -57,29 +57,74 @@
> DEFINE_WD_CLASS(reservation_ww_class);
> EXPORT_SYMBOL(reservation_ww_class);
>
> +/* Mask for the lower fence pointer bits */
> +#define DMA_RESV_LIST_MASK 0x3
> +
> struct dma_resv_list {
> struct rcu_head rcu;
> - u32 shared_count, shared_max;
> - struct dma_fence __rcu *shared[];
> + u32 num_fences, max_fences;
> + struct dma_fence __rcu *table[];
> };
>
> +/**
> + * dma_resv_list_entry - extract fence and usage from a list entry
> + * @list: the list to extract and entry from
> + * @index: which entry we want
> + * @resv: optional dma_resv obj for lockdep check that the access is allowed
> + * @fence: the resulting fence
> + * @usage: the resulting usage
> + *
> + * Extract the fence and usage flags from an RCU protected entry in the list.
> + */
No kerneldoc for static helpers which are internal to .c files. I was
going a bit wtf why would you export such a bad internals-heavy interface
until I realized it's only used in dma-resv.c.
> +static void dma_resv_list_entry(struct dma_resv_list *list, unsigned int
> index,
> + struct dma_resv *resv, struct dma_fence **fence,
> + enum dma_resv_usage *usage)
> +{
> + long tmp;
> +
> + tmp = (long)rcu_dereference_check(list->table[index],
> + resv ? dma_resv_held(resv) : true);
> + *fence = (struct dma_fence *)(tmp & ~DMA_RESV_LIST_MASK);
> + if (usage)
> + *usage = tmp & DMA_RESV_LIST_MASK;
> +}
> +
> +/**
> + * dma_resv_list_set - set fence and usage at a specific index
> + * @list: the list to modify
> + * @index: where to make the change
> + * @fence: the fence to set
[PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
v3: fix a missing case in radeon
v4: rebase on nouveau changes, fix lockdep and temporary disable warning
v5: more documentation updates
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c| 345 --
drivers/dma-buf/st-dma-resv.c | 101 ++---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 13 +-
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +-
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/lima/lima_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +-
drivers/gpu/drm/nouveau/nouveau_fence.c | 4 +-
drivers/gpu/drm/qxl/qxl_release.c | 3 +-
drivers/gpu/drm/radeon/radeon_object.c| 6 +-
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c| 6 +-
drivers/gpu/drm/v3d/v3d_gem.c | 4 +-
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
drivers/gpu/drm/vgem/vgem_fence.c | 9 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 3 +-
include/linux/dma-buf.h | 17 +-
include/linux/dma-resv.h | 72 ++--
26 files changed, 276 insertions(+), 370 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index bb7b023c2d33..26257ba1527e 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -44,12 +44,12 @@
/**
* DOC: Reservation Object Overview
*
- * The reservation object provides a mechanism to manage shared and
- * exclusive fences associated with a buffer. A reservation object
- * can have attached one exclusive fence (normally associated with
- * write operations) or N shared fences (read operations). The RCU
- * mechanism is used to protect read access to fences from locked
- * write-side updates.
+ * The reservation object provides a mechanism to manage a container of
+ * dma_fence object associated with a resource. A reservation object
+ * can have any number of fences attaches to it. Each fence carring an usage
+ * parameter determining how the operation represented by the fence is using
the
+ * resource. The RCU mechanism is used to protect read access to fences from
+ * locked write-side updates.
*
* See struct dma_resv for more details.
*/
@@ -57,29 +57,74 @@
DEFINE_WD_CLASS(reservation_ww_class);
EXPORT_SYMBOL(reservation_ww_class);
+/* Mask for the lower fence pointer bits */
+#define DMA_RESV_LIST_MASK 0x3
+
struct dma_resv_list {
struct rcu_head rcu;
- u32 shared_count, shared_max;
- struct dma_fence __rcu *shared[];
+ u32 num_fences, max_fences;
+ struct dma_fence __rcu *table[];
};
+/**
+ * dma_resv_list_entry - extract fence and usage from a list entry
+ * @list: the list to extract and entry from
+ * @index: which entry we want
+ * @resv: optional dma_resv obj for lockdep check that the access is allowed
+ * @fence: the resulting fence
+ * @usage: the resulting usage
+ *
+ * Extract the fence and usage flags from an RCU protected entry in the list.
+ */
+static void dma_resv_list_entry(struct dma_resv_list *list, unsigned int index,
+ struct dma_resv *resv, struct dma_fence **fence,
+ enum dma_resv_usage *usage)
+{
+ long tmp;
+
+ tmp = (long)rcu_dereference_check(list->table[index],
+ resv ? dma_resv_held(resv) : true);
+ *fence = (struct dma_fence *)(tmp & ~DMA_RESV_LIST_MASK);
+ if (usage)
+ *usage = tmp & DMA_RESV_LIST_MASK;
+}
+
+/**
+ * dma_resv_list_set - set fence and usage at a specific index
+ * @list: the list to modify
+ * @index: where to make the change
+ * @fence: the fence to set
+ * @usage: the usage to set
+ *
+ * Set the fence and usage flags at the specific index in the list.
+ */
+static void dma_resv_list_set(struct dma_resv_list *list,
+ unsigned int index,
+ struct dma_fence *fence,
+ enum dma_resv_usage usage)
+{
+ long tmp = ((long)fence) | usage;
+
+ RCU_INIT_POINTER(list->table[index], (struct dma_fence *)tmp);
+}
+
/**
* dma_resv_list_alloc - allocate fence list
- * @shared_max:
