From 6bc13b1a867a5fd769f2be713ce9c9d863534bff Mon Sep 17 00:00:00 2001 From: Phil Elwell Date: Tue, 28 Aug 2018 10:40:40 +0100 Subject: [PATCH] staging/vc04_services: Derive g_cache_line_size The ARM coprocessor registers include dcache line size, but there is no function to expose this value. Rather than create a new one, use the read_cpuid_id function to derive the correct value, which is 32 for BCM2835 and 64 for BCM2836/7. Signed-off-by: Phil Elwell --- .../interface/vchiq_arm/vchiq_2835_arm.c | 24 +++++++++++++++---- 1 file changed, 19 insertions(+), 5 deletions(-) --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c @@ -42,6 +42,7 @@ #include #include #include +#include #include #define TOTAL_SLOTS (VCHIQ_SLOT_ZERO_SLOTS + 2 * 32) @@ -81,13 +82,15 @@ static void __iomem *g_regs; * VPU firmware, which determines the required alignment of the * offsets/sizes in pagelists. * - * Modern VPU firmware looks for a DT "cache-line-size" property in - * the VCHIQ node and will overwrite it with the actual L2 cache size, + * Previous VPU firmware looked for a DT "cache-line-size" property in + * the VCHIQ node and would overwrite it with the actual L2 cache size, * which the kernel must then respect. That property was rejected - * upstream, so we have to use the VPU firmware's compatibility value - * of 32. + * upstream, so we now rely on both sides to "do the right thing" independently + * of the other. To improve backwards compatibility, this new behaviour is + * signalled to the firmware by the use of a corrected "reg" property on the + * relevant Device Tree node. */ -static unsigned int g_cache_line_size = 32; +static unsigned int g_cache_line_size; static unsigned int g_fragments_size; static char *g_fragments_base; static char *g_free_fragments; @@ -127,6 +130,17 @@ int vchiq_platform_init(struct platform_ if (err < 0) return err; + /* + * The tempting L1_CACHE_BYTES macro doesn't work in the case of + * a kernel built with bcm2835_defconfig running on a BCM2836/7 + * processor, hence the need for a runtime check. The dcache line size + * is encoded in one of the coprocessor registers, but there is no + * convenient way to access it short of embedded assembler, hence + * the use of read_cpuid_id(). The following test evaluates to true + * on a BCM2835 showing that it is ARMv6-ish, whereas + * cpu_architecture() will indicate that it is an ARMv7. + */ + g_cache_line_size = ((read_cpuid_id() & 0x7f000) == 0x7b000) ? 32 : 64; g_fragments_size = 2 * g_cache_line_size; /* Allocate space for the channels in coherent memory */