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: > > > 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>