Re: [RFC PATCH 2/4] pio-mapping: Add ARM support for the PIO mapping API

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2010-02-08 at 16:54 +0000, Russell King wrote:
> On Mon, Feb 08, 2010 at 04:10:21PM +0000, Catalin Marinas wrote:
> > The pio_data_direction could be dropped and use the DMA one. We could
> > also use pio_kmap_read/pio_kmap_write or similar but we have to triple
> > the number of functions, so I prefer the additional argument.
> 
> Do we need to do anything for reading a buffer for PIO _out_ to the
> device?  My understanding is that this has never been a problem.

Before outbound PIO, you need to flush all the aliases before sending.
However, this should *already* be done in the block path, so for block
I/O it should be unnecessary, yes.  All we need to do on the TO_DEVICE
case should be map and unmap the page if it's highmem.

> The only problem I'm aware of is where PIO writes to the kernel
> mapping of a lowmem pages; highmem pages need the data flushed out
> of the temporary atomic kmap mapping anyway.

Not quite.  in the PIO FROM_DEVICE case, we've created a dirty kernel
alias by reading the data from the device and writing it via the kernel
mapping.  We have to flush that alias whether it exists as a highmem
mapping or as a simple offset mapping before userspace will see the
data.  The block API assumes the FROM_DEVICE transfer went straight from
the device into main memory and didn't go via the kernel alias, so the
block use case won't flush it.

Additionally, for architectures that don't promise no movein on a
flushed but untouched page (unlike parisc, which does), we might need to
invalidate all the user aliases before passing the page back to kill any
stale data that may have been speculated into the alias caches).

James