[Top] [All Lists]

Re: Broadcom Swarm support

Subject: Re: Broadcom Swarm support
From: Atsushi Nemoto <>
Date: Tue, 30 Jun 2009 23:00:40 +0900 (JST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
On Mon, 29 Jun 2009 20:08:10 +0100, Ralf Baechle <> wrote:
> > 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.

Thanks, I see.  Then, how about VIPT I-cache case?

> > 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.

Same here.  A physical page used to __init code might be reused for
user code page, so explicit flush (invalide) is required for VIPT
case, no?

Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>