[PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[Christian König]

Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced
user space submissions as well and document the rules around adding the
same fence with different usages.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 include/linux/dma-resv.h | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index c8ccbc94d5d2..264e27e56dff 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -62,6 +62,11 @@ struct dma_resv_list;
  * For example when asking for WRITE fences then the KERNEL fences are returned
  * as well. Similar when asked for READ fences then both WRITE and KERNEL
  * fences are returned as well.
+ *
+ * Already used fences can be promoted in the sense that a fence with
+ * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again
+ * with this usage. But fences can never be degraded in the sense that a fence
+ * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
  */
 enum dma_resv_usage {
 	/**
@@ -98,10 +103,15 @@ enum dma_resv_usage {
 	 * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
 	 *
 	 * This should be used by submissions which don't want to participate in
-	 * implicit synchronization.
+	 * any implicit synchronization.
+	 *
+	 * The most common case are preemption fences, page table updates, TLB
+	 * flushes as well as explicit synced user submissions.
 	 *
-	 * The most common case are preemption fences as well as page table
-	 * updates and their TLB flushes.
+	 * Explicit synced user user submissions can be promoted to
+	 * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
+	 * dma_buf_import_sync_file() when implicit synchronization should
+	 * become necessary after initial adding of the fence.
 	 */
 	DMA_RESV_USAGE_BOOKKEEP
 };
-- 
2.25.1

Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[Alex Deucher]

On Tue, Jul 12, 2022 at 9:12 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced

DMA_RESV_USAGE_BOOKKEEP?

> user space submissions as well and document the rules around adding the
> same fence with different usages.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  include/linux/dma-resv.h | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> index c8ccbc94d5d2..264e27e56dff 100644
> --- a/include/linux/dma-resv.h
> +++ b/include/linux/dma-resv.h
> @@ -62,6 +62,11 @@ struct dma_resv_list;
>   * For example when asking for WRITE fences then the KERNEL fences are returned
>   * as well. Similar when asked for READ fences then both WRITE and KERNEL
>   * fences are returned as well.
> + *
> + * Already used fences can be promoted in the sense that a fence with
> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again

Same here.

With that fixed,
Acked-by: Alex Deucher <alexander.deucher@amd.com>

Alex

> + * with this usage. But fences can never be degraded in the sense that a fence
> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
>   */
>  enum dma_resv_usage {
>         /**
> @@ -98,10 +103,15 @@ enum dma_resv_usage {
>          * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
>          *
>          * This should be used by submissions which don't want to participate in
> -        * implicit synchronization.
> +        * any implicit synchronization.
> +        *
> +        * The most common case are preemption fences, page table updates, TLB
> +        * flushes as well as explicit synced user submissions.
>          *
> -        * The most common case are preemption fences as well as page table
> -        * updates and their TLB flushes.
> +        * Explicit synced user user submissions can be promoted to
> +        * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
> +        * dma_buf_import_sync_file() when implicit synchronization should
> +        * become necessary after initial adding of the fence.
>          */
>         DMA_RESV_USAGE_BOOKKEEP
>  };
> --
> 2.25.1
>
> _______________________________________________
> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org

Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[Christian König]

Am 12.07.22 um 15:20 schrieb Alex Deucher:
> On Tue, Jul 12, 2022 at 9:12 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced
> DMA_RESV_USAGE_BOOKKEEP?

Crappy autocorrect and copy&paste. Thanks for pointing that out.

Christian.

>
>> user space submissions as well and document the rules around adding the
>> same fence with different usages.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   include/linux/dma-resv.h | 16 +++++++++++++---
>>   1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
>> index c8ccbc94d5d2..264e27e56dff 100644
>> --- a/include/linux/dma-resv.h
>> +++ b/include/linux/dma-resv.h
>> @@ -62,6 +62,11 @@ struct dma_resv_list;
>>    * For example when asking for WRITE fences then the KERNEL fences are returned
>>    * as well. Similar when asked for READ fences then both WRITE and KERNEL
>>    * fences are returned as well.
>> + *
>> + * Already used fences can be promoted in the sense that a fence with
>> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again
> Same here.
>
> With that fixed,
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
>
> Alex
>
>> + * with this usage. But fences can never be degraded in the sense that a fence
>> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
>>    */
>>   enum dma_resv_usage {
>>          /**
>> @@ -98,10 +103,15 @@ enum dma_resv_usage {
>>           * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
>>           *
>>           * This should be used by submissions which don't want to participate in
>> -        * implicit synchronization.
>> +        * any implicit synchronization.
>> +        *
>> +        * The most common case are preemption fences, page table updates, TLB
>> +        * flushes as well as explicit synced user submissions.
>>           *
>> -        * The most common case are preemption fences as well as page table
>> -        * updates and their TLB flushes.
>> +        * Explicit synced user user submissions can be promoted to
>> +        * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
>> +        * dma_buf_import_sync_file() when implicit synchronization should
>> +        * become necessary after initial adding of the fence.
>>           */
>>          DMA_RESV_USAGE_BOOKKEEP
>>   };
>> --
>> 2.25.1
>>
>> _______________________________________________
>> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
>> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org

Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[Bas Nieuwenhuizen]

With that changed

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

Thanks!

On Tue, Jul 12, 2022 at 3:23 PM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 12.07.22 um 15:20 schrieb Alex Deucher:
> > On Tue, Jul 12, 2022 at 9:12 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced
> > DMA_RESV_USAGE_BOOKKEEP?
>
> Crappy autocorrect and copy&paste. Thanks for pointing that out.
>
> Christian.
>
> >
> >> user space submissions as well and document the rules around adding the
> >> same fence with different usages.
> >>
> >> Signed-off-by: Christian König <christian.koenig@amd.com>
> >> ---
> >>   include/linux/dma-resv.h | 16 +++++++++++++---
> >>   1 file changed, 13 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> >> index c8ccbc94d5d2..264e27e56dff 100644
> >> --- a/include/linux/dma-resv.h
> >> +++ b/include/linux/dma-resv.h
> >> @@ -62,6 +62,11 @@ struct dma_resv_list;
> >>    * For example when asking for WRITE fences then the KERNEL fences are returned
> >>    * as well. Similar when asked for READ fences then both WRITE and KERNEL
> >>    * fences are returned as well.
> >> + *
> >> + * Already used fences can be promoted in the sense that a fence with
> >> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again
> > Same here.
> >
> > With that fixed,
> > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> >
> > Alex
> >
> >> + * with this usage. But fences can never be degraded in the sense that a fence
> >> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
> >>    */
> >>   enum dma_resv_usage {
> >>          /**
> >> @@ -98,10 +103,15 @@ enum dma_resv_usage {
> >>           * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
> >>           *
> >>           * This should be used by submissions which don't want to participate in
> >> -        * implicit synchronization.
> >> +        * any implicit synchronization.
> >> +        *
> >> +        * The most common case are preemption fences, page table updates, TLB
> >> +        * flushes as well as explicit synced user submissions.
> >>           *
> >> -        * The most common case are preemption fences as well as page table
> >> -        * updates and their TLB flushes.
> >> +        * Explicit synced user user submissions can be promoted to
> >> +        * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
> >> +        * dma_buf_import_sync_file() when implicit synchronization should
> >> +        * become necessary after initial adding of the fence.
> >>           */
> >>          DMA_RESV_USAGE_BOOKKEEP
> >>   };
> >> --
> >> 2.25.1
> >>
> >> _______________________________________________
> >> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
> >> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org
>

Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

[Daniel Vetter]

On Wed, Jul 13, 2022 at 01:27:13PM +0200, Bas Nieuwenhuizen wrote:
> With that changed
> 
> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

Yeah this is a nice clarification.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

In case it hasn't landed yet or so.
-Daniel

> 
> Thanks!
> 
> On Tue, Jul 12, 2022 at 3:23 PM Christian König
> <christian.koenig@amd.com> wrote:
> >
> > Am 12.07.22 um 15:20 schrieb Alex Deucher:
> > > On Tue, Jul 12, 2022 at 9:12 AM Christian König
> > > <ckoenig.leichtzumerken@gmail.com> wrote:
> > >> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced
> > > DMA_RESV_USAGE_BOOKKEEP?
> >
> > Crappy autocorrect and copy&paste. Thanks for pointing that out.
> >
> > Christian.
> >
> > >
> > >> user space submissions as well and document the rules around adding the
> > >> same fence with different usages.
> > >>
> > >> Signed-off-by: Christian König <christian.koenig@amd.com>
> > >> ---
> > >>   include/linux/dma-resv.h | 16 +++++++++++++---
> > >>   1 file changed, 13 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> > >> index c8ccbc94d5d2..264e27e56dff 100644
> > >> --- a/include/linux/dma-resv.h
> > >> +++ b/include/linux/dma-resv.h
> > >> @@ -62,6 +62,11 @@ struct dma_resv_list;
> > >>    * For example when asking for WRITE fences then the KERNEL fences are returned
> > >>    * as well. Similar when asked for READ fences then both WRITE and KERNEL
> > >>    * fences are returned as well.
> > >> + *
> > >> + * Already used fences can be promoted in the sense that a fence with
> > >> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again
> > > Same here.
> > >
> > > With that fixed,
> > > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> > >
> > > Alex
> > >
> > >> + * with this usage. But fences can never be degraded in the sense that a fence
> > >> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
> > >>    */
> > >>   enum dma_resv_usage {
> > >>          /**
> > >> @@ -98,10 +103,15 @@ enum dma_resv_usage {
> > >>           * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
> > >>           *
> > >>           * This should be used by submissions which don't want to participate in
> > >> -        * implicit synchronization.
> > >> +        * any implicit synchronization.
> > >> +        *
> > >> +        * The most common case are preemption fences, page table updates, TLB
> > >> +        * flushes as well as explicit synced user submissions.
> > >>           *
> > >> -        * The most common case are preemption fences as well as page table
> > >> -        * updates and their TLB flushes.
> > >> +        * Explicit synced user user submissions can be promoted to
> > >> +        * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
> > >> +        * dma_buf_import_sync_file() when implicit synchronization should
> > >> +        * become necessary after initial adding of the fence.
> > >>           */
> > >>          DMA_RESV_USAGE_BOOKKEEP
> > >>   };
> > >> --
> > >> 2.25.1
> > >>
> > >> _______________________________________________
> > >> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
> > >> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch