On Tue, Jul 16, 2019 at 01:02:19PM +0100, Robin Murphy wrote: >> Lets say 4k video allocation required 300MB cma memory but not required >> virtual mapping for all the 300MB, its require only 20MB virtually mapped >> at some specific use case/point of video, and unmap virtual mapping after >> uses, at that time this functions will be useful, it works like ioremap() >> for cma_alloc() using dma apis. > > Hmm, is there any significant reason that this case couldn't be handled > with just get_vm_area() plus dma_mmap_attrs(). I know it's only *intended* > for userspace mappings, but since the basic machinery is there... Because the dma helper really are a black box abstraction. That being said DMA_ATTR_NO_KERNEL_MAPPING and DMA_ATTR_NON_CONSISTENT have been a constant pain in the b**t. I've been toying with replacing them with a dma_alloc_pages or similar abstraction that just returns a struct page that is guaranteed to be dma addressable by the passed in device. Then the driver can call dma_map_page / dma_unmap_page / dma_sync_* on it at well. This would replace DMA_ATTR_NON_CONSISTENT with a sensible API, and also DMA_ATTR_NO_KERNEL_MAPPING when called with PageHighmem, while providing an easy to understand API and something that can easily be fed into the various page based APIs in the kernel. That being said until we get arm moved over the common dma direct and dma-iommu code, and x86 fully moved over to dma-iommu it just seems way too much work to even get it into the various architectures that matter, never mind all the fringe IOMMUs. So for now I've just been trying to contain the DMA_ATTR_NON_CONSISTENT and DMA_ATTR_NO_KERNEL_MAPPING in fewer places while also killing bogus or pointless users of these APIs.
