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

[Albert ARIBAUD]

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.

> > Now, if you disable then flush, then any write between the two will go
> > straight to memory without dirtying the cache, and once it is flushed,
> > you end up with coherent cache and memory.
> 
> I had a question here. Would the same logic not apply to the case you
> mention -- in case the cache is disabled and subsequently flushed,
> could there not be a scenario where there is a valid(updated) data
> that gets written to the memory, which then gets overwritten by the
> cache flush. Or am i missing something here.

There could be such a risk indeed, in the following scenario:

- an address gets written into, causing the new value to be cached;
- the cache is disabled;
- the same address is written into again, directly into memory;
- the flush occurs, overwriting the second value with the first.

This scenario requires two subsequent writes of different values to the
same address, which is less likely than the failure scenario of flushing
before disabling, which only requires writing a new value once for any
address:

- the flush occurs;
- an address gets written into, causing the new value to be cached;
- the cache is disabled;
- the value is lost as the cache will be invalidated before being
  re-enabled.

I'll grant you that the current code is not zero-risk, if we ever have
code that double-writes two different values in the same location. But
the proposed RFC increases the risks.

> sughosh

Amicalement,
-- 
Albert.