Date:	Tue, 15 Mar 2011 18:34:42 +0900
From:	daeinki <inki.dae@...sung.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	InKi Dae <daeinki@...il.com>, KyongHo Cho <pullip.cho@...sung.com>,
	Tomasz Stanislawski <t.stanislaws@...sung.com>,
	k.debski@...sung.com, linux-samsung-soc@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	강민규 <mk7.kang@...sung.com>,
	linux-kernel@...r.kernel.org, kyungmin.park@...sung.com,
	kgene.kim@...sung.com, Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
	linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU	(IOMMU)
 driver

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

Powered by blists - more mailing lists