Hi Sughosh,
On Mon, 8 Jul 2013 19:37:22 +0530, Sughosh Ganu urwithsughosh@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@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,