Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU)driver

[daeinki]

Russell King - ARM Linux ì ê:
> On Tue, Mar 15, 2011 at 10:45:50AM +0900, InKi Dae wrote:
> > 2011/3/14 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:
> > > 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.
sorry but I couldn't understand exactly what you said. could you give me 
your answer one more time?
does non-system RAM mean reserved memory regions? if not, is it 
arbitrary virtual address space that isn't kernel or user virtual 
address space and is the space for iommu based deivce?


> > 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@xxxxxxxxxxxxxxxxxxx
> > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/