From 42954857190b9df16d9d873ecc7f6cc38e013e44 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Fern=C3=A1ndez=20Rojas?= Date: Tue, 9 Jul 2019 20:32:28 +0200 Subject: brcm2708: add linux 4.19 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Boot tested on Raspberry Pi B+ (BCM2708) and Raspberry Pi 2 (BCM2709) Signed-off-by: Álvaro Fernández Rojas --- ...ng-vc04_services-Derive-g_cache_line_size.patch | 64 ++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch (limited to 'target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch') diff --git a/target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch b/target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch new file mode 100644 index 0000000000..5894aca1cd --- /dev/null +++ b/target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch @@ -0,0 +1,64 @@ +From 3e89900d7dd7c851400e0afeea326f94bba1cd84 Mon Sep 17 00:00:00 2001 +From: Phil Elwell +Date: Tue, 28 Aug 2018 10:40:40 +0100 +Subject: [PATCH 137/703] 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 */ -- cgit v1.2.3