Re: v7_flush_kern_cache_louis flushes up to L2?

[Jonathan Austin <jonathan.austin@arm.com>]

Hi again Bastian,

On 10/04/13 13:16, Bastian Hecht wrote:
[...]
>>> This flushes the data out up to the L2, right? The ARM docs say that
>>> the Point of Unification would be my L2. I'm a bit confused by the
>>> term "Level of Unification Inner Shareable" (that states that in an
>>> SMP system L1 coherency is guaranteed and all is flushed to the L2?).
>>>
>>
>> As you say, for the A9 (from the TRM) the CLIDR reports LoUIS is the same as
>> LoUU and both specify L2.
>
> Ok, this is the golden info I was looking for. So after cpu_suspend()
> I am good with the following sequence?
> flush L2 (outer_flush_all)
> disable L2 (outer_disable)
> Clear the SCTLR.C bit and issue an "isb"
> flush L1 (v7_flush_dcache_all)

This looks good but I think there's a minor modification to be made to 
the sequence here:

After you turn of the caches with the SCTLR.C bit, you can no longer hit 
in the L1 cache:
SCTLR.C = 0:
"The Cortex-A9 L1 Data Cache is not enabled. All memory accesses to 
Normal Memory Cacheable regions are treated as Normal Memory 
Non-Cacheable, without lookup and without allocation in the L1 Data Cache."

If you had dirty data in the L1 cache you will lose it at that point.

So, you should flush L1 before turning off caches.

Note that on SMP, you would also need to clean/flush again after turning 
off the caches, as read-speculation could have sucked dirty data from 
another cache in to your cache, which would need to be written back 
before sleeping.

> cpu_do_idle
>
> and for resume:
> invalidate L1

How do you plan to do this? I notice that there's an increasing tendency 
to call v7_invalidate_l1 which isn't actually part of the cacheflush API 
(see arch/arm/include/asm/cacheflush.h arch/arm/include/asm/glue-cache.h...)

Does your cache definitely come up in an undefined state? If not, could 
you use v7_flush_dcache_all? (see the comment above v7_invalidate_l1 in 
arch/arm/mm/cache-v7.S)

Hope that helps,

Jonny