target/linux/brcm2708/patches-4.19/950-0137-staging-vc04_services-Derive-g_cache_line_size.patch

   1 From 32c4aeec41ce54e0065e975050152a3f10a6ae6d Mon Sep 17 00:00:00 2001
   2 From: Phil Elwell <phil@raspberrypi.org>
   3 Date: Tue, 28 Aug 2018 10:40:40 +0100
   4 Subject: [PATCH 137/782] staging/vc04_services: Derive g_cache_line_size
   5
   6 The ARM coprocessor registers include dcache line size, but there is no
   7 function to expose this value. Rather than create a new one, use the
   8 read_cpuid_id function to derive the correct value, which is 32 for
   9 BCM2835 and 64 for BCM2836/7.
  10
  11 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
  12 ---
  13  .../interface/vchiq_arm/vchiq_2835_arm.c      | 24 +++++++++++++++----
  14  1 file changed, 19 insertions(+), 5 deletions(-)
  15
  16 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
  17 +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
  18 @@ -42,6 +42,7 @@
  19  #include <linux/uaccess.h>
  20  #include <linux/mm.h>
  21  #include <linux/of.h>
  22 +#include <asm/cputype.h>
  23  #include <soc/bcm2835/raspberrypi-firmware.h>
  24
  25  #define TOTAL_SLOTS (VCHIQ_SLOT_ZERO_SLOTS + 2 * 32)
  26 @@ -81,13 +82,15 @@ static void __iomem *g_regs;
  27   * VPU firmware, which determines the required alignment of the
  28   * offsets/sizes in pagelists.
  29   *
  30 - * Modern VPU firmware looks for a DT "cache-line-size" property in
  31 - * the VCHIQ node and will overwrite it with the actual L2 cache size,
  32 + * Previous VPU firmware looked for a DT "cache-line-size" property in
  33 + * the VCHIQ node and would overwrite it with the actual L2 cache size,
  34   * which the kernel must then respect.  That property was rejected
  35 - * upstream, so we have to use the VPU firmware's compatibility value
  36 - * of 32.
  37 + * upstream, so we now rely on both sides to "do the right thing" independently
  38 + * of the other. To improve backwards compatibility, this new behaviour is
  39 + * signalled to the firmware by the use of a corrected "reg" property on the
  40 + * relevant Device Tree node.
  41   */
  42 -static unsigned int g_cache_line_size = 32;
  43 +static unsigned int g_cache_line_size;
  44  static unsigned int g_fragments_size;
  45  static char *g_fragments_base;
  46  static char *g_free_fragments;
  47 @@ -127,6 +130,17 @@ int vchiq_platform_init(struct platform_
  48         if (err < 0)
  49                 return err;
  50
  51 +       /*
  52 +        * The tempting L1_CACHE_BYTES macro doesn't work in the case of
  53 +        * a kernel built with bcm2835_defconfig running on a BCM2836/7
  54 +        * processor, hence the need for a runtime check. The dcache line size
  55 +        * is encoded in one of the coprocessor registers, but there is no
  56 +        * convenient way to access it short of embedded assembler, hence
  57 +        * the use of read_cpuid_id(). The following test evaluates to true
  58 +        * on a BCM2835 showing that it is ARMv6-ish, whereas
  59 +        * cpu_architecture() will indicate that it is an ARMv7.
  60 +        */
  61 +       g_cache_line_size = ((read_cpuid_id() & 0x7f000) == 0x7b000) ? 32 : 64;
  62         g_fragments_size = 2 * g_cache_line_size;
  63
  64         /* Allocate space for the channels in coherent memory */