[lkml]   [2011]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver

    On Friday, March 11, 2011 12:51 PM Arnd Bergmann wrote:

    > On Friday 11 March 2011, Marek Szyprowski wrote:
    > >
    > > We followed the style of iommu API for other mainline ARM platforms (both OMAP and MSM
    > > also have custom API for their iommu modules). I've briefly checked include/linux/iommu.h
    > > API and I've noticed that it has been designed mainly for KVM support. There is also
    > > include/linux/intel-iommu.h interface, but I it is very specific to intel gfx chips.
    > The MSM code actually uses the generic iommu.h code, using register_iommu, so
    > the drivers can use the regular iommu_map.
    > I believe the omap code predates the iommu API, and should really be changed
    > to use that. At least it was added before I started reviewing the code.
    > The iommu API is not really meant to be KVM specific, it's just that the
    > in-tree users are basically limited to KVM at the moment. Another user that
    > is coming up soon is the vmio device driver that can be used to transparently
    > pass devices to user space. The idea behind the IOMMU API is that you can
    > map arbitrary bus addresses to physical memory addresses, but it does not
    > deal with allocating the bus addresses or providing buffer management such
    > as cache flushes.

    Yea, I've noticed this and this basically what we expect from iommu driver.
    However the iommu.h API requires a separate call to map each single memory page.
    This is quite ineffective approach and imho the API need to be extended to allow
    mapping of the arbitrary set of pages.

    > > Is there any example how include/linux/dma-mapping.h interface can be used for iommu
    > > mappings?
    > The dma-mapping API is the normal interface that you should use for IOMMUs
    > that sit between DMA devices and kernel memory. The idea is that you
    > completely abstract the concept of an IOMMU so the device driver uses
    > the same code for talking to a device with an IOMMU and another device with
    > a linear mapping or an swiotlb bounce buffer.
    > This means that the user of the dma-mapping API does not get to choose the
    > bus addresses, but instead you use the API to get a bus address for a
    > chunk of memory, and then you can pass that address to a device.
    > See arch/powerpc/kernel/iommu.c and arch/x86/kernel/amd_iommu.c for common
    > examples of how this is implemented. The latter one actually implements
    > both the iommu_ops for iommu.h and dma_map_ops for dma-mapping.h.

    Thanks for your comments! We will check how is it suitable for our case.

    Best regards
    Marek Szyprowski
    Samsung Poland R&D Center

     \ /
      Last update: 2011-03-11 13:37    [W:0.075 / U:21.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site