[PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator

Arnd Bergmann arnd at arndb.de
Tue Apr 19 08:00:29 EDT 2011


On Tuesday 19 April 2011, Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote:
> > On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote:
> > > My feeling is that this is not the right abstraction. Why can't you
> > > just implement the regular dma-mapping.h interfaces for your IOMMU
> > > so that the videobuf code can use the existing allocators?
> > 
> > I'm not really sure which existing videobuf2 allocators might transparently
> > support IOMMU interface yet
> > 
> > Do you think that all iommu operations can be hidden behind dma_map_single 
> > and dma_unmap_single?
> 
> That is one of the intentions of the DMA API.

Exactly.

All architectures that support IOMMUs today do that, see:

arch/alpha/kernel/pci_iommu.c
arch/ia64/hp/common/sba_iommu.c
arch/powerpc/kernel/dma-iommu.c
arch/sparc/kernel/iommu.c
arch/x86/kernel/amd_iommu.c

ARM would be the first one to combine an IOMMU with potentially
noncoherent DMA, but there is no fundamental reason why we shouldn't
be able to transparently support an IOMMU.

Ideally, I think we should first find an architecture-independent
way to define an IOMMU in one place instead of having to do both
the iommu.h and dma-mapping.h interfaces, but I wouldn't require
Samsung to do that in order to support their IOMMU. Doing support for
the dma-mapping.h interface should be sufficient there.

	Arnd



More information about the linux-arm-kernel mailing list