On 06/10/2015 03:28 AM, Ralf Baechle wrote:
On Thu, May 28, 2015 at 01:37:24PM -0700, Leonid Yegoshin wrote:
...
I was wondering why there was a cache flush at all so I dove into git
history and found:
commit 4676f9359fa5190ee6f42bbf2c27d28beb14d26a
Author: Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx>
Date: Tue Jan 21 09:48:48 2014 +0000
MIPS: mm: c-r4k: Flush scache to avoid cache aliases
There is a chance for the secondary cache to have memory
aliases. This can happen if the bootloader is in a non-EVA mode
(or even in EVA mode but with different mapping from the kernel)
and the kernel switching to EVA afterwards. It's best to flush
the icache to avoid having the secondary CPUs fetching stale
data from it.
Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx>
Signed-off-by: Markos Chandras <markos.chandras@xxxxxxxxxx>
flush_icache_range() really only is meant to deal with I-cache coherency
issues as they appear during normal kernel operation, that is code is
modified and will be executed from RAM. I doesn't know about aliases
and it's not meant to know.
1) OK, here is an explanation of memory aliasing (don't mix with cache
aliasing).
Memory blocks bigger than 512MB should be put somewhere above 512MB
physical address due to IO hole but we still need some memory at
physical address 0x0000000. Board designers often prefer using masking
of some address bits to MIRROR 256-512MB into 0x00000000 from a primary
memory space location (for Malta - physical address 0x80000000). It
decreases latency by some bus clocks (which are not CPU clocks but slowly).
So, in Malta the word at physical address 0x00000000-256MB is the same
as word at physical address 0x80000000-0x90000000 (other boards may have
another location). But cache subsystem knows NOTHING about it and caches
that memory twice. This is a memory aliasing and it may cause a lot of
trouble if system uses both aliasing address ranges. But it is pretty
often that system initially uses low block 0x00000000->512MB during core
startup and later switches to primary address space. So, some full L1D
and L2 cache flush is needed after cache is initialized. However, after
creation of exception handler code it is still needed additionally a
flush of that code too, in L1D/I and including L2 in EVA, to avoid
memory aliasing problem.
2) This patch actually notices that EJTAG and NMI exception handlers
work with Status.ERL bit and pull exception handler code from uncachable
memory, so a flushing exception handlers down to memory (including L2)
is needed for that because of different reason. Actually, it is a result
of debugging NMI with U-Boot. It is just by chance that it uses the same
code and solution as EVA flushing.
As I understand you only need this on startup. Making this function work
for your special use results in a performance penalty for every other user
of this function.
Function local_r4k_flush_icache_range() can be used only at startup,
before SMP is inialized. Original code has comment above this function:
/* This function is used only for local CPU only while boot etc */
I don't know why it disappeared.
How about reverting this commit and calling __flush_cache_all() to
make sure your kernel code gets flushed out to the other end of the
universe - or memory, what ever comes first?
That function may call SMP IPI in some vendor CPUs and is not suitable.
But I agree that name local_r4k_flush_icache_range() is a not good now
and it may be changed to something more appropriate. I am just not good
in name changing game.
- Leonid.
Ralf
