From mboxrd@z Thu Jan  1 00:00:00 1970
From: jamie@shareable.org (Jamie Lokier)
Date: Mon, 28 Sep 2009 15:15:10 +0100
Subject: arm_syscall cacheflush breakage on VIPT platforms
In-Reply-To: <200909281610.32674.laurent.pinchart@ideasonboard.com>
References: <20090928092919.GA30271@localhost>
	<20090928133109.GM30271@localhost>
	<20090928134232.GG10671@n2100.arm.linux.org.uk>
	<200909281610.32674.laurent.pinchart@ideasonboard.com>
Message-ID: <20090928141510.GG19778@shareable.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Laurent Pinchart wrote:
> > I'd much rather just say "no, userspace DMA is *never* going to ever
> > be supported" and call it a day, but I suspect no one's going to like
> > that either.
> 
> In that case developers will all create their own incompatible solutions and 
> the situation will likely get worse. Do you think it would be possible to 
> create a clean DMA-to-userspace API specific to the ARM architecture ?

I hate to spell out the obvious, but a fine solution is to _not_ DMA
directly to userspace, but to kmalloc() a large buffer in your own
driver, DMA into the buffer (it's kernel memory so that's ok), and
_then_ mmap() that buffer into userspace after the DMA.  Going the
other way, mmap(), write from userspace, munmap(), then do the DMA to
the device.

That's trivial to implement, and the developer's we're talking about
should have no difficulty writing a simple driver like that.  They
have a driver already, it's just a matter of adding the mmap method.

Russell, is there any reason why the above would not work?

-- Jamie