On 2022-01-26 11:54, Hyeonggon Yoo wrote:
Last month we discussed drivers that uses kmalloc(GFP_DMA) for
noncoherent mapping should be converted to use DMA API [1]. Simple
grep with GFP_DMA shows that many of drivers are mistakenly
using GFP_DMA flag.
So our purpose was to make DMA API choose right zone depending on
device's dma mask. Baoquan and I are trying to make drivers to
use dma_alloc_noncoherent() when allocating the buffer.
But it's not simple for some of drivers; there is a gap between
dma_alloc_noncoherent() and the previous convention (allocating buffer
from buddy or slab allocator and mapping it when needed.)
For example, some drivers allocate buffer and reuse it. it just maps
and unmaps whenever needed. And some drivers does not even maps the
buffer. (some drivers that does not use DMA API)
So I think we need to implement a version of dma_alloc_noncoherent()
that does not map the buffer.
This doesn't make sense to me. The point of dma_alloc_* is you get back
a dedicated DMA buffer which can then be used at any time. In the
noncoherent case you have to put in explicit dma_sync_*() calls around
accesses when the CPU or device is expected to have updated the buffer
contents, but it's still fundamentally the same paradigm.
If you want to update drivers from using streaming mappings on
specially-allocated pages to using proper dedicated DMA buffers, then
update the logic in those drivers to use dedicated DMA buffers
appropriately. Adding an API to allocate a DMA buffer which isn't
actually a DMA buffer so we can "update" drivers from misusing streaming
mappings to still misusing streaming mappings is nonsense.
Robin.
I think implementing a helper that internally calls
__dma_direct_alloc_pages() will be okay.
As I'm not expert in this area, I want to hear
others' opinions.
[1] https://lkml.org/lkml/2021/12/13/1121
Thanks,
Hyeonggon.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
