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