brcm2708: add linux 4.19 support

Boot tested on Raspberry Pi B+ (BCM2708) and Raspberry Pi 2 (BCM2709)

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>

1 files changed, 64 insertions, 0 deletions

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 <phil@raspberrypi.org>
+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 <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 */