arm64: IOMMU-backed DMA mapping
Get series with b4
b4 am [email protected]Versions newest first
- v4 Latest0 of 4 patches 0 repliesNew
Patches in v4 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v4 yet.
Cover letter [PATCH v4 0/4] arm64: IOMMU-backed DMA mapping
Hi Joerg, Robin,
Quoted 18 lines · Robin Murphy
Quoted 7 lines · Joerg Roedel
Quoted 3 lines · Robin Murphy
arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 15 +- arch/arm64/mm/dma-mapping.c | 452 +++++++++++++++++++++++++++++What happened to the plan to merge this with the existing iommu-based dma-api implementation for 32 bit ARM?
The issue currently is that there are a bunch of drivers using the exported arm_iommu_* functions directly. From what I can tell, they seem like they could probably all be converted to using default domains and/or the new domain type abstractions via the core IOMMU API, which would then allow killing off
dma_iommu_mappingand rewriting thearch/armimplementation to use the new shared code. I don't currently have any 32-bit platform to test with, so I'm a little dubious of taking that all on myself right now.
Quoted 5 lines
In the meantime on arm64, DMA mapping ops are needed for SMMUv3 platform device support, the Mediatek M4U patches and my own SMMUv2 work, so it would be very useful to get the arm64 and common code in as a first step, then look at cleaning up
arch/armfor 4.4 without dangling dependencies.
What's the plan with this? Do we need to port 32-bit ARM before it's a candidate for merging, or can we push ahead with getting this up and running for arm64 (which currently can't use an IOMMU for DMA)?
Will