On Monday 18 April 2011, Tony Lindgren wrote: > * Arnd Bergmann <arnd@xxxxxxxx> [110418 10:26]: > > On Friday 15 April 2011, Russell King - ARM Linux wrote: > > > On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote: > > > > From: Ramesh Gupta <grgupta@xxxxxx> > > > > > > > > This patch is to flush the iommu page table entries from L1 and L2 > > > > caches using dma_map_single. This also simplifies the implementation > > > > by removing the functions flush_iopgd_range/flush_iopte_range. > > > > > > No. This usage is just wrong. If you're going to use the DMA API then > > > unmap it, otherwise the DMA API debugging will go awol. > > > > > > It's also completely upside-down: The iommu support should provide interfaces > > using the dma-mapping API, not use that API to provide a machine specific > > version of the generic interface. > > > > As far as I can tell, nothing actually uses these drivers, maybe we should just > > remove them before we get any code in the mainline kernel that depends on it. > > There is drivers/media/video/omap3isp/isp.c. Ah, I didn't see that, was looking at an older version. > But if we now have a generic replacement for this code we should start > using it. To give some background: Historically, the dma-mapping API has been used for all IOMMUs on architectures that need it. This interface is rather flexible, but ARM currently only uses it for managing static mappings. One thing that it cannot do is mapping memory to an arbitrary (driver-chosen) bus address. The generic iommu API was added in order to do that, and is mostly used for virtual machines with KVM. The MSM platform in ARM also added support for the generic iommu API, and now the exynos4 is gaining support for it as well. One missing piece is still a way for a platform to provide both the iommu and the dma-mapping API in a unified driver. Right now, you have to export both interface for a generic solution. On ARM, we don't yet use include/asm-generic/dma-mapping-common.h, which allows overriding the dma-mapping API per device. This would have to change if you want to export the IOMMU functionality using the dma-mapping API, but that would also allow abstracting the various ways we currently have (dmabounce, swiotlb, linear map, custom __arch_page_to_dma, iommu, coherent or noncoherent DMA) in a nicer way per device. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
