On Tue, Dec 07, 2021 at 01:34:07PM +0100, Christian König wrote:
Add an usage for kernel submissions. Waiting for those are mandatory for dynamic DMA-bufs.
Signed-off-by: Christian König christian.koenig@amd.com
Again just skipping to the doc bikeshedding, maybe with more cc others help with some code review too.
EXPORT_SYMBOL(ib_umem_dmabuf_map_pages); diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index 4f3a6abf43c4..29d799991496 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -54,8 +54,30 @@ struct dma_resv_list;
- This enum describes the different use cases for a dma_resv object and
- controls which fences are returned when queried.
- An important fact is that there is the order KERNEL<WRITE<READ and
- when the dma_resv object is asked for fences for one use case the fences
- for the lower use case are returned as well.
- 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.
enum dma_resv_usage {
- /**
* @DMA_RESV_USAGE_KERNEL: For in kernel memory management only.** This should only be used for things like copying or clearing memory* with a DMA hardware engine for the purpose of kernel memory* management.** Drivers *always* need to wait for those fences before accessing the
s/need to/must/ to stay with usual RFC wording. It's a hard requirement or there's a security bug somewhere.
* resource protected by the dma_resv object. The only exception for* that is when the resource is known to be locked down in place by* pinning it previously.
Is this true? This sounds more confusing than helpful, because afaik in general our pin interfaces do not block for any kernel fences. dma_buf_pin doesn't do that for sure. And I don't think ttm does that either.
I think the only safe thing here is to state that it's safe if a) the resource is pinned down and b) the callers has previously waited for the kernel fences.
I also think we should put that wait for kernel fences into dma_buf_pin(), but that's maybe a later patch. -Daniel
*/- DMA_RESV_USAGE_KERNEL,
- /**
- @DMA_RESV_USAGE_WRITE: Implicit write synchronization.
-- 2.25.1