Thread (32 messages) 32 messages, 4 authors, 2011-04-26

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

From: arnd@arndb.de (Arnd Bergmann)
Date: 2011-04-19 12:00:36
Also in: linux-media, linux-samsung-soc

On Tuesday 19 April 2011, Russell King - ARM Linux wrote:
On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote:
quoted
On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help