On Mon, May 28, 2012 at 10:19:39AM +0200, Marek Szyprowski wrote:
Hello,
On Sunday, May 27, 2012 2:35 PM KOSAKI Motohiro wrote:
On Thu, May 24, 2012 at 8:28 AM, Paul Mundt lethal@linux-sh.org wrote:
On Thu, May 24, 2012 at 02:26:12PM +0200, Marek Szyprowski wrote:
On Tuesday, May 22, 2012 9:08 AM Minchan Kim wrote:
Hmm, VM_DMA would become generic flag? AFAIU, maybe VM_DMA would be used only on ARM arch.
Right now yes, it will be used only on ARM architecture, but maybe other architecture will start using it once it is available.
There's very little about the code in question that is ARM-specific to begin with. I plan to adopt similar changes on SH once the work has settled one way or the other, so we'll probably use the VMA flag there, too.
I don't think VM_DMA is good idea because x86_64 has two dma zones. x86 unaware patches make no sense.
I see no problems to add VM_DMA64 later if x86_64 starts using vmalloc areas for creating kernel mappings for the dma buffers (I assume that there are 2 dma zones: one 32bit and one 64bit). Right now x86 and x86_64 don't use vmalloc areas for dma buffers, so I hardly see how this patch can be considered as 'x86 unaware'.
Well they do - kind off. It is usually done by calling vmalloc_32 and then using the DMA API on top of those pages (or sometimes the non-portable virt_to_phys macro).
Introducing this and replacing the vmalloc_32 with this seems like a nice step in making those device drivers APIs more portable?