[U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[york sun]

On 11/07/2016 06:12 AM, Mark Rutland wrote:
> On Fri, Oct 28, 2016 at 09:35:37PM +0000, york sun wrote:
>> I am struggling on the dcache_disable() which implies all dcache is
>> flushed. I don't have a reasonable way to flush all if I want to skip
>> L3. I tried to benchmark flushing by VA to cover my entire 16GB memory.
>> It took 30+ seconds. On the other side, flushing by set/way and flushing
>> L3 together took 7 ms. If I only flush U-Boot stack in this function, it
>> can run really fast, but that defeats the purpose of flush all cache.
>>
>> I thought of parsing each set/way to find the address of each cache line
>> (I don't know how to do that yet), but the tag only contains physical
>> address not VA.
>
> With the MMU off, translation is an idmap (i.e. VA == PA), so if you
> have physical addresses, you can use those directly.
>
> That said, the presence and implementation of any mechanism to read
> addresses from the cache is IMPLEMENTATION DEFINED, so this will not be
> portable.
>
>> The ARM document shows example code to clean entire data or unified
>> cache to PoC, very similar to the code we have in U-Boot armv8/cache.S.
>
> Do you mean the "Example code for cache maintenance instructions"?
>
> In recent versions of the ARM ARM there's a large note explaining why
> this only works in very restricted scenarios (and cannot be used to
> affect system caches such as your L3).
>
> In the latest ARM ARM ("ARM DDI 0487A.k"), see page D3-1710.
>
>> Unless there are other cache maintenance instruction I am not aware of,
>> I don't see how to flush to PoC by set/way.
>
> Architecturally, Set/Way operations are not guaranteed to affect al
> caches prior to the PoC, and may require other IMPLEMENTATION DEFINED
> maintenance (e.g. MMIO control of system-level caches).
>

At this point, seeking alternative ways to clean entire cache without 
flushing L3 seems non-productive. I am going to stop here. Thanks for 
the discussion.

York