Hi Marek, On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski <m.szyprow...@samsung.com> wrote: > This patch replaces ARM-specific IOMMU-based DMA-mapping implementation > with generic IOMMU DMA-mapping code shared with ARM64 architecture. The > side-effect of this change is a switch from bitmap-based IO address space > management to tree-based code. There should be no functional changes > for drivers, which rely on initialization from generic arch_setup_dna_ops() > interface. Code, which used old arm_iommu_* functions must be updated to > new interface. > > Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com> > ---
Thanks for your efforts and my apologies for late comments. Just FYI I'll try your patch (and this series) with the ipmmu-vmsa.c driver on 32-bit ARM and see how it goes. Nice not to have to support multiple interfaces depending on architecture! One question that comes to mind is how to handle features. For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS while the shared code in drivers/iommu/dma-iommu.c does not. I assume existing users may rely on such features so from my point of view it probably makes sense to carry over features from the 32-bit ARM code into the shared code before pulling the plug. I also wonder if it is possible to do a step-by-step migration and support both old and new interfaces in the same binary? That may make things easier for multiplatform enablement. So far I've managed to make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with the shared code in drivers/iommu/dma-iommu.c may also be possible. And probably involving even more ugly magic. =) Cheers, / magnus
