brcm2708: rename target to bcm27xx

[openwrt/openwrt.git] / target / linux / brcm2708 / patches-4.19 / 950-0129-staging-vc04_services-Derive-g_cache_line_size.patch

diff --git a/target/linux/brcm2708/patches-4.19/950-0129-staging-vc04_services-Derive-g_cache_line_size.patch b/target/linux/brcm2708/patches-4.19/950-0129-staging-vc04_services-Derive-g_cache_line_size.patch
deleted file mode 100644 (file)
index f7bc93f..0000000
--- a/target/linux/brcm2708/patches-4.19/950-0129-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 <phil@raspberrypi.org>
-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 <phil@raspberrypi.org>
----
- .../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 <linux/uaccess.h>
- #include <linux/mm.h>
- #include <linux/of.h>
-+#include <asm/cputype.h>
- #include <soc/bcm2835/raspberrypi-firmware.h>
- 
- #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 */