[U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

[Albert ARIBAUD]

Hi Sughosh,

On Mon, 8 Jul 2013 19:37:22 +0530, Sughosh Ganu
<urwithsughosh at gmail.com> wrote:

> hi Albert,
> 
> On Mon Jul 08, 2013 at 02:32:16PM +0200, Albert ARIBAUD wrote:
> > Hi Sughosh,
> > 
> > On Mon, 8 Jul 2013 17:38:46 +0530, Sughosh Ganu
> > <urwithsughosh at gmail.com> wrote:
> > 
> > > hi Albert,
> > > On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:
> > > 
> > > <snip>
> > > 
> > > > It you flush first then disable, you leave a time window between the
> > > > two where a write to the cache can happen (either because your code
> > > > does one, or because the compiler optimized one in). If it happens,
> > > > then you disable a cache which is still dirty -- IOW, your flushing
> > > > has failed its mission, and your cache and memory are still not
> > > > coherent.
> > > 
> > > Since this is specific to arm926ejs, can we not flush *and* invalidate
> > > the dcache before disabling it -- since the arm926ejs cache uses a
> > > read allocate policy, flushing and invalidating a cache before
> > > disabling it would not result in the cache getting written to in the
> > > window that you refer to. Also, flushing and cleaning is an atomic
> > > operation.
> > 
> > Invalidating the cache in addition to flushing it would not prevent
> > further writes from dirtying the cache lines if they happen before
> > the cache is disabled.
> 
> I have a doubt on this. The arm926ejs uses a read-allocate policy,
> wherein a new cache line is allocated only on a read miss -- a write
> to an address not present in the cache gets written to memory. So if
> the cache line is invalidated, how will data get written to the cache.

The arm926ej-s data cache does not have a single fixed policy, and
does not have a bypass-on-write policy, only write-through and
copy-back.

Other, more complex, policies may be defined, but at the MMU, not cache,
level, and those are not constant for all arm926ej-s based SoCs; not
even constant for a given SoC as they are configurable at run-time to
fit the chosen system addressing map.

(Besides, bypassing the cache for writes and not reads is of little
interest for plain DDR caching.)

> -sughosh

Amicalement,
-- 
Albert.