| Message ID | 20220712131201.131475-1-christian.koenig@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dma-buf/dma_resv_usage: update explicit sync documentation | expand |
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
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
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 >
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 > >
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 };
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(-)