lkml.org 
[lkml]   [2011]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
    On Tue, Mar 15, 2011 at 10:45:50AM +0900, InKi Dae wrote:
    > 2011/3/14 Russell King - ARM Linux <linux@arm.linux.org.uk>:
    > > On Mon, Mar 14, 2011 at 09:37:51PM +0900, KyongHo Cho wrote:
    > >> I have also noticed that dma_map_single/page/sg() can map physical
    > >> memory into an arbitrary device address region.
    > >> But it is not enough solution for various kinds of IOMMUs.
    > >> As Kukjin Kim addressed, we need to support larger page size than 4KB
    > >> because we can reduce TLB miss when we have larger page size.
    > >>
    > >> Our IOMMU(system mmu) supports all page size of ARM architecture
    > >> including 16MB, 1MB, 64KB and 4KB.
    > >> Since the largest size supported by buddy system of 32-bit architecture is 4MB,
    > >> our system support all page sizes except 16MB.
    > >> We proved that larger page size is helpful for DMA performance
    > >> significantly (more than 10%, approximately).
    > >> Big page size is not a problem for peripheral devices
    > >> because their address space is not suffer from external fragmentation.
    > >
    > > 1. dma_map_single() et.al. is used for mapping *system* *RAM* for devices
    > >   using whatever is necessary.  It must not be used for trying to setup
    > >   arbitary other mappings.
    > >
    > > 2. It doesn't matter where the memory for dma_map_single() et.al. comes
    > >   from provided the virtual address is a valid system RAM address or
    > >   the struct page * is a valid struct page in the memory map (iow, you
    > >   can't create this yourself.)
    >
    > You mean that we cannot have arbitrary virtual address mapping for
    > iommu based device?

    No. I mean exactly what I said - I'm talking about the DMA API in the
    above two points. The implication is that you can not create arbitary
    mappings of non-system RAM with the DMA API.

    > actually, we have memory mapping to arbitrary device virtual address
    > space, not kernel virtual address space.
    >
    > >
    > > 3. In the case of an IOMMU, the DMA API does not limit you to only using
    > >   4K pages to setup the IOMMU mappings.  You can use whatever you like
    > >   provided the hardware can cope with it.  You can coalesce several
    > >   existing entries together provided you track what you're doing and can
    > >   undo what's been done when the mapping is no longer required.
    > >
    > > So really there's no reason not to use 64K, 1M and 16M IOMMU entries if
    > > that's the size of buffer which has been passed to the DMA API.
    > >
    > > _______________________________________________
    > > linux-arm-kernel mailing list
    > > linux-arm-kernel@lists.infradead.org
    > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
    > >
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-03-15 09:37    [W:4.966 / U:0.588 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site