Hello,

On Friday, July 29, 2011 12:54 PM Joerg Roedel wrote:

On Fri, Jul 29, 2011 at 12:14:25PM +0200, Marek Szyprowski wrote:

quoted

quoted

This sounds rather hacky. How about partitioning the address space for
the device and give the dma-api only a part of it. The other parts can
be directly mapped using the iommu-api then.

Well, I'm not convinced that iommu-api should be used by the device drivers
directly. If possible we should rather extend dma-mapping than use such

hacks.

Building this into dma-api would turn it into an iommu-api. The line
between the apis are clear. The iommu-api provides direct mapping
of bus-addresses to system-addresses while the dma-api puts a memory
manager on-top which deals with bus-address allocation itself.
So if you want to map bus-addresses directly the iommu-api is the way to
go. This is in no way a hack.

The problem starts when you want to use the same driver on two different
systems:
one with iommu and one without. Our driver depends only on dma-mapping and the
fact
that the first allocation starts from the right address. On systems without
iommu,
board code calls bootmem_reserve() and dma_declare_coherent() for the required 
memory range. Systems with IOMMU just sets up device io address space to start 
at the specified address. This works fine, because in our system each device has
its own, private iommu controller and private address space.

Right now I have no idea how to handle this better. Perhaps with should be
possible
to specify somehow the target dma_address when doing memory allocation, but I'm
not
really convinced yet if this is really required.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center