[RFC] ARM: increase L1_CACHE_SHIFT

[RFC] ARM: increase L1_CACHE_SHIFT

[Aaro Koskinen]

Hello,

ARM Cortex-A8 has 64 byte cache line, so the current code is
wrong. This is little worrying if you e.g. read the comments from
eb5f4ca9536ba297c98721ecbbdf41ec5b987bd5.

What would be the proper way to handle this? Should we set it to 64
bytes for everyone, or set it according to some #define or Kconfig option?

---
 arch/arm/include/asm/cache.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index feaa75f..b786b24 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -4,7 +4,7 @@
 #ifndef __ASMARM_CACHE_H
 #define __ASMARM_CACHE_H
 
-#define L1_CACHE_SHIFT		5
+#define L1_CACHE_SHIFT		6
 #define L1_CACHE_BYTES		(1 << L1_CACHE_SHIFT)
 
 /*
-- 
1.5.4.3

[RFC] ARM: increase L1_CACHE_SHIFT

[Mikael Pettersson]

Aaro Koskinen writes:
 > Hello,
 > 
 > ARM Cortex-A8 has 64 byte cache line, so the current code is
 > wrong. This is little worrying if you e.g. read the comments from
 > eb5f4ca9536ba297c98721ecbbdf41ec5b987bd5.
 > 
 > What would be the proper way to handle this? Should we set it to 64
 > bytes for everyone, or set it according to some #define or Kconfig option?

It should be an internal (not user-selectable) CONFIG symbol
synthesized from the CPU type selection option. See e.g. the
x86 Kconfig for an example on how this can be done.

It's probably cleaner to have the CPU selection options "select"
appropriate L1_CACHE_SHIFT_$N options than to force the L1_CACHE_SHIFT
option to enumerate all possible CPU types for a given shift value.

/Mikael

[RFC] ARM: increase L1_CACHE_SHIFT

[Russell King - ARM Linux]

On Mon, Aug 31, 2009 at 11:30:30AM +0200, Mikael Pettersson wrote:
> Aaro Koskinen writes:
>  > Hello,
>  > 
>  > ARM Cortex-A8 has 64 byte cache line, so the current code is
>  > wrong. This is little worrying if you e.g. read the comments from
>  > eb5f4ca9536ba297c98721ecbbdf41ec5b987bd5.
>  > 
>  > What would be the proper way to handle this? Should we set it to 64
>  > bytes for everyone, or set it according to some #define or Kconfig option?
> 
> It should be an internal (not user-selectable) CONFIG symbol
> synthesized from the CPU type selection option. See e.g. the
> x86 Kconfig for an example on how this can be done.
> 
> It's probably cleaner to have the CPU selection options "select"
> appropriate L1_CACHE_SHIFT_$N options than to force the L1_CACHE_SHIFT
> option to enumerate all possible CPU types for a given shift value.

The problem is that L1_CACHE_SHIFT must be at least the cache line size
of the CPU which you're going to be running on.  From an architectural
point of view, this is something which is only really known at run time
and doesn't really bear any relationship to the CPU architecture version.
However, L1_CACHE_SHIFT needs to be a compile time constant.

Eg, an ARMv6 CPU could have 128 byte cache lines.  I don't know of such
a device though.  However, it would be silly to enforce a 128 byte lines
on all ARMv6 CPUs.

Maybe the approach we should take is to have CONFIG_L1_CACHE_SHIFT be
an integer between 5 and 7, and default it according to the architecture
selected (so 5 for anything pre-Cortex A8, and 6 for Cortex A8).