From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sughosh Ganu <urwithsughosh@gmail.com>
Date: Mon, 8 Jul 2013 17:49:45 +0530
Subject: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable
 it
In-Reply-To: <20130708122257.5f0100ec@lilith>
References: <1372768555-12477-1-git-send-email-voice.shen@gmail.com>
	<20130705230200.5c64c39c@lilith> <51D9FABE.7000705@gmail.com>
	<20130708122257.5f0100ec@lilith>
Message-ID: <20130708121945.GA6159@Hardy>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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 invalidating is an atomic
operation.

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

-sughosh