RFC arm64: IOMMU-backed DMA mapping
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
Hi Marek,
Quoted 12 lines · Marek Szyprowski
Hello,
Quoted 8 lines · Robin Murphy
Hi all,
Whilst it's a long way off perfect, this has reached the point of being functional and stable enough to be useful, so here it is. The core consists of the meat of the
arch/armimplementation modified to remove the assumption ofPAGE_SIZEpages and ported over to the Intel IOVA allocator instead of the bitmap-based one. For that, this series depends on my "Genericise the IOVA allocator" series posted earlier[1].
Quoted 4 lines
I've tested your patches on Exynos 5433 based system and I have a few comments. To get them working I had to do some fixes. Most of them are already reported in this thread, the remaining I will send in a few minutes.
Thanks!
Quoted 1 line
Do you plan to send an updated patchset?
I already sent a v2 which addressed some of the major issues here:
http://thread.gmane.org/gmane.linux.kernel.iommu/8773
Following some of the feedback there I've currently got a v3 in development, which reworks a lot of it more in favour of scatterlists, and fills in some of the gaps needed to move arch/arm over (I still need to look at how to handle the drivers currently making use of dma_iommu_mapping directly).
Robin.
Quoted 34 lines
Quoted 12 lines
There are plenty of obvious things still to do, including:
* Domain and group handling is all wrong, but that's a bigger problem. For the moment it does more or less the same thing as the
arch/armcode, which at least works for the one-IOMMU-per-device situation.
* IOMMU domains and IOVA domains probably want to be better integrated with devices and each other, rather than having a proliferation of arch-specific structs.
* The temporarymap_sgimplementation - I have a 'proper'iommu_map_sgbased one in progress, but since the simple one works it's not been as high a priority.Well, for ARM arch this was the main feature of IOMMU and DMA-mapping integration. It is heavily used by some multimedia devices and dma-buf realted stuff to get a scattered buffer mapped into contiguous IO address space.
Quoted 2 lines
* Port
arch/armover to it. I'd guess it might be preferable to merge this through arm64 first, though, rather than overcomplicate matters.I think that the code in
arch/armis already quite well tested and can be almost directly reused for common dma-mapping helpers.Quoted 7 lines
* There may well be scope for streamlining and tidying up the copied parts - In general I've simply avoided touching anything I don't fully understand.
* In the same vein, I'm sure lots of it is fairly ARM-specific, so will need longer-term work to become truly generic.Best regards