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 };
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
*/ enum dma_resv_usage { /**
- with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
@@ -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
*/ enum dma_resv_usage { /**
- with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
@@ -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
*/ enum dma_resv_usage { /**
- with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
@@ -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
linaro-mm-sig@lists.linaro.org
-
Alex Deucher -
Bas Nieuwenhuizen -
Christian König -
Christian König -
Daniel Vetter