X-Git-Url: http://git.openwrt.org/?a=blobdiff_plain;f=target%2Flinux%2Fbrcm2708%2Fpatches-4.19%2F950-0132-staging-vc04_services-Derive-g_cache_line_size.patch;fp=target%2Flinux%2Fbrcm2708%2Fpatches-4.19%2F950-0132-staging-vc04_services-Derive-g_cache_line_size.patch;h=0000000000000000000000000000000000000000;hb=c2308a7e4adbb2acc8ff149f91d1ca46801c135e;hp=f7bc93fdb88afd56b06f2089f066107d16ce3d79;hpb=67dcc43f3a22dc3a7ac07a7065971b426feeb043;p=openwrt%2Fstaging%2Fchunkeey.git diff --git a/target/linux/brcm2708/patches-4.19/950-0132-staging-vc04_services-Derive-g_cache_line_size.patch b/target/linux/brcm2708/patches-4.19/950-0132-staging-vc04_services-Derive-g_cache_line_size.patch deleted file mode 100644 index f7bc93fdb8..0000000000 --- a/target/linux/brcm2708/patches-4.19/950-0132-staging-vc04_services-Derive-g_cache_line_size.patch +++ /dev/null @@ -1,64 +0,0 @@ -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 */