[PATCH 0/3] Cache maintenance on VIPT caches

[Catalin Marinas]

On Tue, 2010-07-20 at 12:37 +0100, Catalin Marinas wrote:
> On Tue, 2010-07-20 at 18:56 +0900, FUJITA Tomonori wrote:
> > On Fri, 16 Jul 2010 15:39:17 +0100
> > Catalin Marinas <catalin.marinas at arm.com> wrote:
> >
> > > On Fri, 2010-07-16 at 14:19 +0100, Rabin VINCENT wrote:
> > > > I ask because the
> > > > mmci patches that I posted convert that driver to use the sg_miter API
> > > > (which uses flush_kernel_dcache_page() internally), and not do any
> > > > flushing inside the driver itself.  Or do you think it would be
> > > > appropriate to have the driver call flush_dcache_page() explicitly?
> > > > (Although this would be double flushing on systems with aliasing caches
> > > > where flush_kernel_dcache_page() is not a no-op.)
> > >
> > > I'm not sure why sg_miter doesn't call flush_dcache_page() but
> > > flush_kernel_dcache_page() (I cc'ed Fujita as he seems to have added
> > > this code).
> >
> > It is intended to handle D aliasing due to kmap. As cachetlb.txt says
> > that it is assumed here that the user has no incoherent cached copies
> > (it was already addressed elsewhere). So flush_dcache_page() does too
> > much there.
> 
> OK. So in this case a PIO driver using sg_miter should still call
> flush_dcache_page() as usual (or not at all as we change the meaning
> PG_arch_1 for the architectures where this matters).

Actually the flush_dcache_page() call in drivers is still useful on SMP
systems where the cache maintenance must happen on the CPU that dirtied
the cache (ARM11MPCore), though I have a workaround for this as well
(doing a 'read-for-ownership' before flushing the D-cache).

-- 
Catalin