Re: [patch for 2.6.33? 1/1] ata: call flush_dcache_page() around PIO data transfers in libata-aff.c

[David Miller <davem@davemloft.net>]

From: James Bottomley <James.Bottomley@suse.de>
Date: Wed, 03 Feb 2010 10:40:54 -0600

> Actually, thinking about the semantics, the normal kmap has to have
> these flushes in the map and unmap anyway ... otherwise the page gets
> decohered if you do normal read/write on it.  The only information we
> don't have in current kmap is whether we're mapping for read/write or
> both.  So the API I'd propose is keep current kmap as is for the read
> and write case, and introduce a kmap_for_read and kmap_for_write (with
> corresponding umaps, and obviously atomics).

This would basically force non-highmem platforms to implement the
kmap_*() interfaces.

I understand that MIPS does this already to deal with cache aliasing.

But that's currently a choice, and sparc64 for example has no need
to do things that way.  It would in fact be more expensive than
how sparc64 currently handles cache aliasing.

So I'm more in support of a new interface.  Platforms like sparc64
can implement it and then get rid of the ide_*() string op cache
flushes and instead we put the new API calls in the right spots.