Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
Hi Marek, On 05/03/15 14:31, Marek Szyprowski wrote: Hello, On 2015-01-12 21:48, Robin Murphy wrote: 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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. 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! 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. 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/arm code, 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 temporary map_sg implementation - I have a 'proper' iommu_map_sg based 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. * Port arch/arm over 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/arm is already quite well tested and can be almost directly reused for common dma-mapping helpers. * 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. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 Best regards ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
Hello, On 2015-01-12 21:48, Robin Murphy wrote: 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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. 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. Do you plan to send an updated patchset? 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/arm code, 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 temporary map_sg implementation - I have a 'proper' iommu_map_sg based 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. * Port arch/arm over 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/arm is already quite well tested and can be almost directly reused for common dma-mapping helpers. * 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. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 23/01/15 16:47, Catalin Marinas wrote: On Mon, Jan 12, 2015 at 08:48:52PM +, Robin Murphy wrote: Catalin Marinas (1): arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy (4): arm64: implement generic IOMMU configuration iommu: implement common IOMMU ops for DMA mapping arm64: add IOMMU dma_ops arm64: hook up IOMMU dma_ops I queued the first two patches in this series for 3.20. The rest need to go through some review rounds. Thanks. Thanks Catalin, the less to rebase the better ;) Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On Mon, Jan 12, 2015 at 08:48:52PM +, Robin Murphy wrote: > Catalin Marinas (1): > arm64: Combine coherent and non-coherent swiotlb dma_ops > > Robin Murphy (4): > arm64: implement generic IOMMU configuration > iommu: implement common IOMMU ops for DMA mapping > arm64: add IOMMU dma_ops > arm64: hook up IOMMU dma_ops I queued the first two patches in this series for 3.20. The rest need to go through some review rounds. Thanks. -- Catalin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 16/01/15 07:21, Yong Wu wrote: [...] Now that the server seems to be properly accessible again, I've made a branch with both series available here: git://linux-arm.org/linux-rm iommu/dma Note that in the current state it also depends on having the ARM SMMU driver selected in the config, due to an oversight on my part :( Robin. Dear Robin, We have test this patch on our SOC(mt8173),which have our own iommu HW(it is not ARM SMMU), the patch could work well. Tested-by:Yong Wu Thanks! And I have some questiones about the usage: 1) If we create a iommu domain by “arch_setup_dma_ops", then we would like to call the standard iommu interface, like “iommu_set_fault_handle”, How can we get the "struct iommu_domain *"? (the “dev_domain” is static.) 2) If a device A call “arch_setup_dma_ops” to create a iommu domain, and a client device B would like to join this iommu domain, so it call “iommu_dma_attach_device”. then the device B want to alloc the iommu memory, it call “dma_alloc_attrs” whose first parameter should be the “struct device *”of device A. Is it designed like this in this patch? (In arch/arm, “dev->archdata.dma_ops = &iommu_dma_ops” is in “arm_iommu_attach_devce”; In this patch, this sentence is in “arch_setup_dma_ops”). At this point there's not really any support for devices managing their own IOMMUs - initially I've only been focusing on the case where dma-mapping handles everything transparently, with legacy 32-bit peripherals in mind. There's already been quite a lot of discussion over the shortcomings of the current arch_setup_dma_ops model (most recently, [1]), but it just-about-works on Juno where we have a single device behind each IOMMU (with the exception of the USB OHCI which falls foul of the domain-per-device approach and falls over because it can't understand addresses from the EHCI). We really need to get IOMMU groups working in order to manage domains properly, which for one thing requires fixing the current situation of devices getting attached to a domain before they've even been added to the bus. I've started looking into that, but I suspect it's going to be long and complicated. 3) void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, struct iommu_ops *iommu, bool coherent) In this function, the second and third parameter are the dma address base and size, can they work currently? (take a example, I set the dma_base is 0, size is 0x4000 while calling arch_setup_dma_ops, then I alloc a range iova whose size is 50*SZ_4K, the return iova is 0xfffce000, it is over 0x4000.) That'll be coming from __alloc_iova using the device's dma_mask as an upper limit. Whilst I'm not sure if having fixed translations per dma-ranges makes sense with an IOMMU present, there does seem to be a valid case for having a size smaller than the driver's dma_mask - e.g. a device that just happens to have some upper address lines tied off in a particular implementation - so I'll change that to properly respect the dma-ranges values. Robin. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On Thu, 2015-01-15 at 18:35 +, Robin Murphy wrote: > On 13/01/15 08:02, Yingjoe Chen wrote: > > On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote: > >> 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/arm implementation modified to remove > >> the assumption of PAGE_SIZE pages 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]. > > > > Hi Robin, > > > > We'd to give it a try. Do you have a public git tree contains both > > series? > > > > Joe.C > > Now that the server seems to be properly accessible again, I've made a > branch with both series available here: > >git://linux-arm.org/linux-rm iommu/dma > > Note that in the current state it also depends on having the ARM SMMU > driver selected in the config, due to an oversight on my part :( > > Robin. > Dear Robin, We have test this patch on our SOC(mt8173),which have our own iommu HW(it is not ARM SMMU), the patch could work well. Tested-by:Yong Wu And I have some questiones about the usage: 1) If we create a iommu domain by “arch_setup_dma_ops", then we would like to call the standard iommu interface, like “iommu_set_fault_handle”, How can we get the "struct iommu_domain *"? (the “dev_domain” is static.) 2) If a device A call “arch_setup_dma_ops” to create a iommu domain, and a client device B would like to join this iommu domain, so it call “iommu_dma_attach_device”. then the device B want to alloc the iommu memory, it call “dma_alloc_attrs” whose first parameter should be the “struct device *”of device A. Is it designed like this in this patch? (In arch/arm, “dev->archdata.dma_ops = &iommu_dma_ops” is in “arm_iommu_attach_devce”; In this patch, this sentence is in “arch_setup_dma_ops”). 3) void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, struct iommu_ops *iommu, bool coherent) In this function, the second and third parameter are the dma address base and size, can they work currently? (take a example, I set the dma_base is 0, size is 0x4000 while calling arch_setup_dma_ops, then I alloc a range iova whose size is 50*SZ_4K, the return iova is 0xfffce000, it is over 0x4000.) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 13/01/15 08:02, Yingjoe Chen wrote: On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote: 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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. Hi Robin, We'd to give it a try. Do you have a public git tree contains both series? Joe.C Now that the server seems to be properly accessible again, I've made a branch with both series available here: git://linux-arm.org/linux-rm iommu/dma Note that in the current state it also depends on having the ARM SMMU driver selected in the config, due to an oversight on my part :( Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote: > 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/arm implementation modified to remove > the assumption of PAGE_SIZE pages 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]. Hi Robin, We'd to give it a try. Do you have a public git tree contains both series? Joe.C ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 13/01/15 08:02, Yingjoe Chen wrote: On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote: 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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. Hi Robin, We'd to give it a try. Do you have a public git tree contains both series? Thanks! Unfortunately I don't have a public tree yet, but I'll try to get one set up shortly. Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 13/01/15 11:08, Stefano Stabellini wrote: On Mon, 12 Jan 2015, Robin Murphy wrote: 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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. 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/arm code, 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 temporary map_sg implementation - I have a 'proper' iommu_map_sg based one in progress, but since the simple one works it's not been as high a priority. * Port arch/arm over to it. I'd guess it might be preferable to merge this through arm64 first, though, rather than overcomplicate matters. * 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. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 I tried to git-am and build a v3.19-rc4 kernel with this series (config file attached), but I get: In file included from include/linux/dma-mapping.h:82:0, from arch/arm64/kernel/asm-offsets.c:23: ./arch/arm64/include/asm/dma-mapping.h: In function ‘phys_to_dma’: ./arch/arm64/include/asm/dma-mapping.h:69:2: error: ‘struct dev_archdata’ has no member named ‘mapping’ ./arch/arm64/include/asm/dma-mapping.h: In function ‘dma_to_phys’: ./arch/arm64/include/asm/dma-mapping.h:81:19: error: ‘struct dev_archdata’ has no member named ‘mapping’ make[1]: *** [arch/arm64/kernel/asm-offsets.s] Error 1 Oops, looks like I've been relying on having an actual IOMMU driver select CONFIG_IOMMU_API - enabling the ARM SMMU driver as well as "IOMMU hardware support" makes everything build, even if it doesn't actually work with the new framework (the patches for that exist, but are currently a big ugly mess). The nested #include guard in arch/arm64/include/asm/device.h in patch 4 is to blame - on reflection, I guess that isn't a great idea regardless of the logical dependency (I don't think my Kconfig-fu is strong enough to guarantee that dependency is enforced). Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On Mon, 12 Jan 2015, Robin Murphy wrote: > 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/arm implementation modified to remove > the assumption of PAGE_SIZE pages 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]. > > 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/arm >code, 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 temporary map_sg implementation - I have a 'proper' iommu_map_sg >based one in progress, but since the simple one works it's not been >as high a priority. > * Port arch/arm over to it. I'd guess it might be preferable to merge >this through arm64 first, though, rather than overcomplicate matters. > * 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. > > [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 I tried to git-am and build a v3.19-rc4 kernel with this series (config file attached), but I get: In file included from include/linux/dma-mapping.h:82:0, from arch/arm64/kernel/asm-offsets.c:23: ./arch/arm64/include/asm/dma-mapping.h: In function ‘phys_to_dma’: ./arch/arm64/include/asm/dma-mapping.h:69:2: error: ‘struct dev_archdata’ has no member named ‘mapping’ ./arch/arm64/include/asm/dma-mapping.h: In function ‘dma_to_phys’: ./arch/arm64/include/asm/dma-mapping.h:81:19: error: ‘struct dev_archdata’ has no member named ‘mapping’ make[1]: *** [arch/arm64/kernel/asm-offsets.s] Error 1# # Automatically generated file; DO NOT EDIT. # Linux/arm64 3.19.0-rc4 Kernel Configuration # CONFIG_ARM64=y CONFIG_64BIT=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CSUM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_HAVE_GENERIC_RCU_GUP=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_KERNEL_MODE_NEON=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_NOCB_CPU is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFI
[RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
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/arm implementation modified to remove the assumption of PAGE_SIZE pages 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]. 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/arm code, 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 temporary map_sg implementation - I have a 'proper' iommu_map_sg based one in progress, but since the simple one works it's not been as high a priority. * Port arch/arm over to it. I'd guess it might be preferable to merge this through arm64 first, though, rather than overcomplicate matters. * 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. [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208 Catalin Marinas (1): arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy (4): arm64: implement generic IOMMU configuration iommu: implement common IOMMU ops for DMA mapping arm64: add IOMMU dma_ops arm64: hook up IOMMU dma_ops arch/arm64/Kconfig | 1 + arch/arm64/include/asm/device.h | 3 + arch/arm64/include/asm/dma-mapping.h | 33 +-- arch/arm64/kernel/setup.c| 2 + arch/arm64/mm/dma-mapping.c | 435 - include/linux/dma-iommu.h| 78 ++ lib/Kconfig | 8 + lib/Makefile | 1 + lib/dma-iommu.c | 455 +++ 9 files changed, 938 insertions(+), 78 deletions(-) create mode 100644 include/linux/dma-iommu.h create mode 100644 lib/dma-iommu.c -- 1.9.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
