Re: Broadcom Swarm support

[Ralf Baechle <ralf@linux-mips.org>]

On Sun, Jun 28, 2009 at 01:09:06AM +0900, Atsushi Nemoto wrote:

> > The I-cache for page just being loaded is clean so no flushing needed.  It
> > is clean because when the page has been unmapped it was flushed or because
> > the CPU switched to a fresh ASID.
> 
> Then, flush_cache_range or flush_cache_page should be called then the
> page was unmmapped, right?  How about flush_cache_mm?  It does not
> flush icache currently.

If that is being called then we're either about to terminate a process or
to exec a new process.  In either case flush_tlb_cache (on VIVT I-cache)
will drop the tlb context which effectively is a full I-cache flush.

> And how about kernel __init code pages?  These pages are just freed on
> free_initmem.  Also how about code pages used by a module which is to
> be unloaded from kernel?

Init code pages won't be used to store code that will be executed at
KSEG0 or XKPHYS addresses so I-cache coherency is not of interest.

For modules the I-cache is being flushed on loading of the module, see
calls to flush_icache_range() in kernel/module.c so I-cache coherency is
not of concern on module unload.

> > The reason for this bug is that when data is being shoveled around by the
> > processor (as opposed to DMA) as on PIO block devices it'll end up sitting
> > in the D-cache so I-cache refills will grab stale data from S-cache or
> > memory.
> 
> Yes, I suppose so on this swarm case, but I'm just thinking of other
> case breaking icache coherency...

Be careful with that - you might succeed ;-)

  Ralf