[lkml]   [2011]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] ARM DMA mapping TODO, v1
    On Wed, Apr 27, 2011 at 08:35:14AM +0100, Russell King - ARM Linux wrote:
    > On Thu, Apr 21, 2011 at 09:29:16PM +0200, Arnd Bergmann wrote:

    > dma_map_ops design is broken - we can't have the entire DMA API indirected
    > through that structure. Whether you have an IOMMU or not is completely
    > independent of whether you have to do DMA cache handling. Moreover, with
    > dmabounce, having the DMA cache handling in place doesn't make sense.
    > So you can't have a dma_map_ops for the cache handling bits, a dma_map_ops
    > for IOMMU, and a dma_map_ops for the dmabounce stuff. It just doesn't
    > work like that.

    Nobody says that the complete feature-set of the dma_ops needs to be
    provided through the IOMMU-API. The different APIs are there to solve
    different problems:

    The IOMMU-API provides low-level access to IOMMU hardware and to map io
    addresses to physical addresses (which can be chosen by the caller). The
    IOMMU-API does not care about address space layout or cache management.

    The DMA-API cares about address management. Every dma_ops implementation
    using an IOMMU has an address allocator for io addresses implemented.
    the DMA-API also cares about cache-management.

    So if we can abstract the different IOMMUs on all architectures in the
    IOMMU-API I see no reason why we can't have a common dma_ops
    implementation. The dma-buffer ownership management (cpu<->device) can
    be put into archtectural call-backs so that architectures that need it
    just implement them and everything should work.

    Or I am too naive to believe that (which is possible because of my
    limited ARM knowledge). In this case please correct me :)



     \ /
      Last update: 2011-04-28 12:43    [W:0.025 / U:0.740 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site