[PATCH v3 0/3] Add Hisilicon L3 cache controller support

[PATCH v3 0/3] Add Hisilicon L3 cache controller support

[Zhen Lei]

v2 --> v3:
Add Hisilicon L3 cache controller driver and its document. That's: patch 2-3.

v1 --> v2:
Discard the middle-tier functions and do silent narrowing cast in the outcache
hook functions. For example:
-static void l2c220_inv_range(unsigned long start, unsigned long end)
+static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;


v1:
Do cast phys_addr_t to unsigned long by adding a middle-tier function.
For example:
-static void l2c220_inv_range(unsigned long start, unsigned long end)
+static void __l2c220_inv_range(unsigned long start, unsigned long end)
 {
 	...
 }
+static void l2c220_inv_range(phys_addr_t start, phys_addr_t end)
+{
+  __l2c220_inv_range(start, end);
+}


Zhen Lei (3):
  ARM: LPAE: Use phys_addr_t instead of unsigned long in outercache
    hooks
  dt-bindings: arm: hisilicon: Add binding for L3 cache controller
  ARM: Add Hisilicon L3 cache controller support

 .../bindings/arm/hisilicon/l3cache.yaml       |  37 +++++
 arch/arm/include/asm/outercache.h             |   6 +-
 arch/arm/mm/Kconfig                           |   9 ++
 arch/arm/mm/Makefile                          |   1 +
 arch/arm/mm/cache-feroceon-l2.c               |  15 +-
 arch/arm/mm/cache-hisi-l3.c                   | 153 ++++++++++++++++++
 arch/arm/mm/cache-hisi-l3.h                   |  30 ++++
 arch/arm/mm/cache-l2x0.c                      |  50 ++++--
 arch/arm/mm/cache-tauros2.c                   |  15 +-
 arch/arm/mm/cache-uniphier.c                  |   6 +-
 arch/arm/mm/cache-xsc3l2.c                    |  12 +-
 11 files changed, 305 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml
 create mode 100644 arch/arm/mm/cache-hisi-l3.c
 create mode 100644 arch/arm/mm/cache-hisi-l3.h

-- 
2.26.0.106.g9fadedd

[PATCH v3 1/3] ARM: LPAE: Use phys_addr_t instead of unsigned long in outercache hooks

[Zhen Lei]

The outercache of some Hisilicon SOCs support physical addresses wider
than 32-bits. The unsigned long datatype is not sufficient for mapping
physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE:
use phys_addr_t instead of unsigned long in outercache functions") has
already modified the outercache functions. But the parameters of the
outercache hooks are not changed. This patch use phys_addr_t instead of
unsigned long in outercache hooks: inv_range, clean_range, flush_range.

To ensure the outercache that does not support LPAE works properly, do
cast phys_addr_t to unsigned long by adding a group of temporary
variables. For example:
-static void l2c220_inv_range(unsigned long start, unsigned long end)
+static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;

Note that the outercache functions have been doing this cast before this
patch. So now, the cast is just moved into the outercache hook functions.

No functional change.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 arch/arm/include/asm/outercache.h |  6 ++--
 arch/arm/mm/cache-feroceon-l2.c   | 15 ++++++++--
 arch/arm/mm/cache-l2x0.c          | 50 ++++++++++++++++++++++---------
 arch/arm/mm/cache-tauros2.c       | 15 ++++++++--
 arch/arm/mm/cache-uniphier.c      |  6 ++--
 arch/arm/mm/cache-xsc3l2.c        | 12 ++++++--
 6 files changed, 75 insertions(+), 29 deletions(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index 3364637755e86aa..4cee1ea0c15449a 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -14,9 +14,9 @@
 struct l2x0_regs;
 
 struct outer_cache_fns {
-	void (*inv_range)(unsigned long, unsigned long);
-	void (*clean_range)(unsigned long, unsigned long);
-	void (*flush_range)(unsigned long, unsigned long);
+	void (*inv_range)(phys_addr_t, phys_addr_t);
+	void (*clean_range)(phys_addr_t, phys_addr_t);
+	void (*flush_range)(phys_addr_t, phys_addr_t);
 	void (*flush_all)(void);
 	void (*disable)(void);
 #ifdef CONFIG_OUTER_CACHE_SYNC
diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
index 5c1b7a7b9af6300..10f909744d5e963 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -168,8 +168,11 @@ static unsigned long calc_range_end(unsigned long start, unsigned long end)
 	return range_end;
 }
 
-static void feroceon_l2_inv_range(unsigned long start, unsigned long end)
+static void feroceon_l2_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	/*
 	 * Clean and invalidate partial first cache line.
 	 */
@@ -198,8 +201,11 @@ static void feroceon_l2_inv_range(unsigned long start, unsigned long end)
 	dsb();
 }
 
-static void feroceon_l2_clean_range(unsigned long start, unsigned long end)
+static void feroceon_l2_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	/*
 	 * If L2 is forced to WT, the L2 will always be clean and we
 	 * don't need to do anything here.
@@ -217,8 +223,11 @@ static void feroceon_l2_clean_range(unsigned long start, unsigned long end)
 	dsb();
 }
 
-static void feroceon_l2_flush_range(unsigned long start, unsigned long end)
+static void feroceon_l2_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	start &= ~(CACHE_LINE_SIZE - 1);
 	end = (end + CACHE_LINE_SIZE - 1) & ~(CACHE_LINE_SIZE - 1);
 	while (start != end) {
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 43d91bfd2360086..cdaddd772b09ede 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -184,8 +184,10 @@ static void __l2c210_op_pa_range(void __iomem *reg, unsigned long start,
 	}
 }
 
-static void l2c210_inv_range(unsigned long start, unsigned long end)
+static void l2c210_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 
 	if (start & (CACHE_LINE_SIZE - 1)) {
@@ -203,8 +205,10 @@ static void l2c210_inv_range(unsigned long start, unsigned long end)
 	__l2c210_cache_sync(base);
 }
 
-static void l2c210_clean_range(unsigned long start, unsigned long end)
+static void l2c210_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 
 	start &= ~(CACHE_LINE_SIZE - 1);
@@ -212,8 +216,10 @@ static void l2c210_clean_range(unsigned long start, unsigned long end)
 	__l2c210_cache_sync(base);
 }
 
-static void l2c210_flush_range(unsigned long start, unsigned long end)
+static void l2c210_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 
 	start &= ~(CACHE_LINE_SIZE - 1);
@@ -304,8 +310,10 @@ static unsigned long l2c220_op_pa_range(void __iomem *reg, unsigned long start,
 	return flags;
 }
 
-static void l2c220_inv_range(unsigned long start, unsigned long end)
+static void l2c220_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
@@ -331,8 +339,10 @@ static void l2c220_inv_range(unsigned long start, unsigned long end)
 	raw_spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-static void l2c220_clean_range(unsigned long start, unsigned long end)
+static void l2c220_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
@@ -350,8 +360,10 @@ static void l2c220_clean_range(unsigned long start, unsigned long end)
 	raw_spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-static void l2c220_flush_range(unsigned long start, unsigned long end)
+static void l2c220_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
@@ -464,8 +476,10 @@ static const struct l2c_init_data l2c220_data = {
  *	Affects: store buffer
  *	store buffer is not automatically drained.
  */
-static void l2c310_inv_range_erratum(unsigned long start, unsigned long end)
+static void l2c310_inv_range_erratum(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	void __iomem *base = l2x0_base;
 
 	if ((start | end) & (CACHE_LINE_SIZE - 1)) {
@@ -496,8 +510,10 @@ static void l2c310_inv_range_erratum(unsigned long start, unsigned long end)
 	__l2c210_cache_sync(base);
 }
 
-static void l2c310_flush_range_erratum(unsigned long start, unsigned long end)
+static void l2c310_flush_range_erratum(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	raw_spinlock_t *lock = &l2x0_lock;
 	unsigned long flags;
 	void __iomem *base = l2x0_base;
@@ -1400,12 +1416,12 @@ static void aurora_pa_range(unsigned long start, unsigned long end,
 		start = range_end;
 	}
 }
-static void aurora_inv_range(unsigned long start, unsigned long end)
+static void aurora_inv_range(phys_addr_t start, phys_addr_t end)
 {
 	aurora_pa_range(start, end, AURORA_INVAL_RANGE_REG);
 }
 
-static void aurora_clean_range(unsigned long start, unsigned long end)
+static void aurora_clean_range(phys_addr_t start, phys_addr_t end)
 {
 	/*
 	 * If L2 is forced to WT, the L2 will always be clean and we
@@ -1415,7 +1431,7 @@ static void aurora_clean_range(unsigned long start, unsigned long end)
 		aurora_pa_range(start, end, AURORA_CLEAN_RANGE_REG);
 }
 
-static void aurora_flush_range(unsigned long start, unsigned long end)
+static void aurora_flush_range(phys_addr_t start, phys_addr_t end)
 {
 	if (l2_wt_override)
 		aurora_pa_range(start, end, AURORA_INVAL_RANGE_REG);
@@ -1604,8 +1620,10 @@ static inline unsigned long bcm_l2_phys_addr(unsigned long addr)
 		return addr + BCM_VC_EMI_OFFSET;
 }
 
-static void bcm_inv_range(unsigned long start, unsigned long end)
+static void bcm_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long new_start, new_end;
 
 	BUG_ON(start < BCM_SYS_EMI_START_ADDR);
@@ -1631,8 +1649,10 @@ static void bcm_inv_range(unsigned long start, unsigned long end)
 		new_end);
 }
 
-static void bcm_clean_range(unsigned long start, unsigned long end)
+static void bcm_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long new_start, new_end;
 
 	BUG_ON(start < BCM_SYS_EMI_START_ADDR);
@@ -1658,8 +1678,10 @@ static void bcm_clean_range(unsigned long start, unsigned long end)
 		new_end);
 }
 
-static void bcm_flush_range(unsigned long start, unsigned long end)
+static void bcm_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long new_start, new_end;
 
 	BUG_ON(start < BCM_SYS_EMI_START_ADDR);
diff --git a/arch/arm/mm/cache-tauros2.c b/arch/arm/mm/cache-tauros2.c
index 88255bea65e41e6..d768bbb5e05c690 100644
--- a/arch/arm/mm/cache-tauros2.c
+++ b/arch/arm/mm/cache-tauros2.c
@@ -66,8 +66,11 @@ static inline void tauros2_inv_pa(unsigned long addr)
  */
 #define CACHE_LINE_SIZE		32
 
-static void tauros2_inv_range(unsigned long start, unsigned long end)
+static void tauros2_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	/*
 	 * Clean and invalidate partial first cache line.
 	 */
@@ -95,8 +98,11 @@ static void tauros2_inv_range(unsigned long start, unsigned long end)
 	dsb();
 }
 
-static void tauros2_clean_range(unsigned long start, unsigned long end)
+static void tauros2_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
 		tauros2_clean_pa(start);
@@ -106,8 +112,11 @@ static void tauros2_clean_range(unsigned long start, unsigned long end)
 	dsb();
 }
 
-static void tauros2_flush_range(unsigned long start, unsigned long end)
+static void tauros2_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
+
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
 		tauros2_clean_inv_pa(start);
diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index ff2881458504329..e2508358e9f4082 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -250,17 +250,17 @@ static void uniphier_cache_maint_all(u32 operation)
 		__uniphier_cache_maint_all(data, operation);
 }
 
-static void uniphier_cache_inv_range(unsigned long start, unsigned long end)
+static void uniphier_cache_inv_range(phys_addr_t start, phys_addr_t end)
 {
 	uniphier_cache_maint_range(start, end, UNIPHIER_SSCOQM_CM_INV);
 }
 
-static void uniphier_cache_clean_range(unsigned long start, unsigned long end)
+static void uniphier_cache_clean_range(phys_addr_t start, phys_addr_t end)
 {
 	uniphier_cache_maint_range(start, end, UNIPHIER_SSCOQM_CM_CLEAN);
 }
 
-static void uniphier_cache_flush_range(unsigned long start, unsigned long end)
+static void uniphier_cache_flush_range(phys_addr_t start, phys_addr_t end)
 {
 	uniphier_cache_maint_range(start, end, UNIPHIER_SSCOQM_CM_FLUSH);
 }
diff --git a/arch/arm/mm/cache-xsc3l2.c b/arch/arm/mm/cache-xsc3l2.c
index d20d7af02d10fc0..5814731653d9091 100644
--- a/arch/arm/mm/cache-xsc3l2.c
+++ b/arch/arm/mm/cache-xsc3l2.c
@@ -83,8 +83,10 @@ static inline unsigned long l2_map_va(unsigned long pa, unsigned long prev_va)
 #endif
 }
 
-static void xsc3_l2_inv_range(unsigned long start, unsigned long end)
+static void xsc3_l2_inv_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long vaddr;
 
 	if (start == 0 && end == -1ul) {
@@ -127,8 +129,10 @@ static void xsc3_l2_inv_range(unsigned long start, unsigned long end)
 	dsb();
 }
 
-static void xsc3_l2_clean_range(unsigned long start, unsigned long end)
+static void xsc3_l2_clean_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long vaddr;
 
 	vaddr = -1;  /* to force the first mapping */
@@ -165,8 +169,10 @@ static inline void xsc3_l2_flush_all(void)
 	dsb();
 }
 
-static void xsc3_l2_flush_range(unsigned long start, unsigned long end)
+static void xsc3_l2_flush_range(phys_addr_t pa_start, phys_addr_t pa_end)
 {
+	unsigned long start = pa_start;
+	unsigned long end = pa_end;
 	unsigned long vaddr;
 
 	if (start == 0 && end == -1ul) {
-- 
2.26.0.106.g9fadedd

[PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Zhen Lei]

Add devicetree binding for Hisilicon L3 cache controller.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 .../bindings/arm/hisilicon/l3cache.yaml       | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml b/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml
new file mode 100644
index 000000000000000..f411818bad23741
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/l3cache.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon L3 cache controller
+
+maintainers:
+  - Wei Xu <xuwei5@hisilicon.com>
+
+description: |
+  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
+  addresses. The data cached in the L3 outer cache can be operated based on the
+  physical address range or the entire cache.
+
+properties:
+  compatible:
+    items:
+      - const: hisilicon,l3cache
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    l3cache@f302b000 {
+        compatible = "hisilicon,l3cache";
+        reg = <0xf302b000 0x1000>;
+    };
+...
-- 
2.26.0.106.g9fadedd

[PATCH v3 3/3] ARM: Add Hisilicon L3 cache controller support

[Zhen Lei]

Support for the Hisilicon L3 cache controller as used with Hi1215 and
Hi1381.

These Hisilicon SoCs support LPAE, so the physical addresses is wider than
32-bits, but the actual bit width does not exceed 36 bits. When the cache
operation is performed based on the address range, the upper 30 bits of
the physical address are recorded in registers L3_MAINT_START and
L3_MAINT_END, and ignore the lower 6 bits cacheline offset.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 arch/arm/mm/Kconfig         |   9 +++
 arch/arm/mm/Makefile        |   1 +
 arch/arm/mm/cache-hisi-l3.c | 153 ++++++++++++++++++++++++++++++++++++
 arch/arm/mm/cache-hisi-l3.h |  30 +++++++
 4 files changed, 193 insertions(+)
 create mode 100644 arch/arm/mm/cache-hisi-l3.c
 create mode 100644 arch/arm/mm/cache-hisi-l3.h

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 02692fbe2db5c59..73cd28419d731df 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1070,6 +1070,15 @@ config CACHE_XSC3L2
 	help
 	  This option enables the L2 cache on XScale3.
 
+config CACHE_HISI_L3
+	bool "Enable the L3 cache on Hisilicon SoCs"
+	depends on ARCH_HISI && OF
+	default y
+	select OUTER_CACHE
+	help
+	  This option enables the L3 cache on Hisilicon SoCs. It supports a maximum
+	  of 36-bit physical addresses.
+
 config ARM_L1_CACHE_SHIFT_6
 	bool
 	default y if CPU_V7
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 3510503bc5e688b..745d55ecb2ed4fd 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_CACHE_L2X0_PMU)	+= cache-l2x0-pmu.o
 obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
 obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
 obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
+obj-$(CONFIG_CACHE_HISI_L3)	+= cache-hisi-l3.o
 
 KASAN_SANITIZE_kasan_init.o	:= n
 obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm/mm/cache-hisi-l3.c b/arch/arm/mm/cache-hisi-l3.c
new file mode 100644
index 000000000000000..7aa590f378a1ef3
--- /dev/null
+++ b/arch/arm/mm/cache-hisi-l3.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Hisilicon Limited.
+ */
+
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+
+#include <asm/cacheflush.h>
+
+#include "cache-hisi-l3.h"
+
+static DEFINE_SPINLOCK(l3cache_lock);
+static void __iomem *l3_ctrl_base;
+
+
+static void l3cache_maint_common(u32 range, u32 op_type)
+{
+	u32 reg;
+
+	reg = readl(l3_ctrl_base + L3_MAINT_CTRL);
+	reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK);
+	reg |= range | op_type;
+	reg |= L3_MAINT_STATUS_START;
+	writel(reg, l3_ctrl_base + L3_MAINT_CTRL);
+
+	/* Wait until the hardware maintenance operation is complete. */
+	do {
+		cpu_relax();
+		reg = readl(l3_ctrl_base + L3_MAINT_CTRL);
+	} while ((reg & L3_MAINT_STATUS_MASK) != L3_MAINT_STATUS_END);
+}
+
+static void l3cache_maint_range(phys_addr_t start, phys_addr_t end, u32 op_type)
+{
+	start = start >> L3_CACHE_LINE_SHITF;
+	end = ((end - 1) >> L3_CACHE_LINE_SHITF) + 1;
+
+	writel(start, l3_ctrl_base + L3_MAINT_START);
+	writel(end, l3_ctrl_base + L3_MAINT_END);
+
+	l3cache_maint_common(L3_MAINT_RANGE_ADDR, op_type);
+}
+
+static inline void l3cache_flush_all_nolock(void)
+{
+	l3cache_maint_common(L3_MAINT_RANGE_ALL, L3_MAINT_TYPE_FLUSH);
+}
+
+static void l3cache_flush_all(void)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l3cache_lock, flags);
+	l3cache_flush_all_nolock();
+	spin_unlock_irqrestore(&l3cache_lock, flags);
+}
+
+static void l3cache_inv_range(phys_addr_t start, phys_addr_t end)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l3cache_lock, flags);
+	l3cache_maint_range(start, end, L3_MAINT_TYPE_INV);
+	spin_unlock_irqrestore(&l3cache_lock, flags);
+}
+
+static void l3cache_clean_range(phys_addr_t start, phys_addr_t end)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l3cache_lock, flags);
+	l3cache_maint_range(start, end, L3_MAINT_TYPE_CLEAN);
+	spin_unlock_irqrestore(&l3cache_lock, flags);
+}
+
+static void l3cache_flush_range(phys_addr_t start, phys_addr_t end)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l3cache_lock, flags);
+	l3cache_maint_range(start, end, L3_MAINT_TYPE_FLUSH);
+	spin_unlock_irqrestore(&l3cache_lock, flags);
+}
+
+static void l3cache_disable(void)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l3cache_lock, flags);
+	l3cache_flush_all_nolock();
+	writel(L3_CTRL_DISABLE, l3_ctrl_base + L3_CTRL);
+	spin_unlock_irqrestore(&l3cache_lock, flags);
+}
+
+static const struct of_device_id l3cache_ids[] __initconst = {
+	{.compatible = "hisilicon,l3cache", .data = NULL},
+	{}
+};
+
+static int __init l3cache_init(void)
+{
+	u32 reg;
+	struct device_node *node;
+
+	node = of_find_matching_node(NULL, l3cache_ids);
+	if (!node)
+		return -ENODEV;
+
+	l3_ctrl_base = of_iomap(node, 0);
+	if (!l3_ctrl_base) {
+		pr_err("failed to map l3cache control registers\n");
+		return -ENOMEM;
+	}
+
+	reg = readl(l3_ctrl_base + L3_CTRL);
+	if (!(reg & L3_CTRL_ENABLE)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&l3cache_lock, flags);
+
+		/*
+		 * Ensure that no L3 cache hardware maintenance operations are
+		 * being performed before enabling the L3 cache. Wait for it to
+		 * finish.
+		 */
+		do {
+			cpu_relax();
+			reg = readl(l3_ctrl_base + L3_MAINT_CTRL);
+		} while ((reg & L3_MAINT_STATUS_MASK) != L3_MAINT_STATUS_END);
+
+		reg = readl(l3_ctrl_base + L3_AUCTRL);
+		reg |= L3_AUCTRL_EVENT_EN | L3_AUCTRL_ECC_EN;
+		writel(reg, l3_ctrl_base + L3_AUCTRL);
+
+		writel(L3_CTRL_ENABLE, l3_ctrl_base + L3_CTRL);
+
+		spin_unlock_irqrestore(&l3cache_lock, flags);
+	}
+
+	outer_cache.inv_range = l3cache_inv_range;
+	outer_cache.clean_range = l3cache_clean_range;
+	outer_cache.flush_range = l3cache_flush_range;
+	outer_cache.flush_all = l3cache_flush_all;
+	outer_cache.disable = l3cache_disable;
+
+	pr_info("Hisilicon l3cache controller enabled\n");
+
+	return 0;
+}
+arch_initcall(l3cache_init);
diff --git a/arch/arm/mm/cache-hisi-l3.h b/arch/arm/mm/cache-hisi-l3.h
new file mode 100644
index 000000000000000..6ec3ee21ae01417
--- /dev/null
+++ b/arch/arm/mm/cache-hisi-l3.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __CACHE_HISI_L3_H
+#define __CACHE_HISI_L3_H
+
+#define L3_CACHE_LINE_SHITF		6
+
+#define L3_CTRL				0x0
+#define L3_CTRL_ENABLE			(1U << 0)
+#define L3_CTRL_DISABLE			(0U << 0)
+
+#define L3_AUCTRL			0x4
+#define L3_AUCTRL_EVENT_EN		BIT(23)
+#define L3_AUCTRL_ECC_EN		BIT(8)
+
+#define L3_MAINT_CTRL			0x20
+#define L3_MAINT_RANGE_MASK		GENMASK(3, 3)
+#define L3_MAINT_RANGE_ALL		(0U << 3)
+#define L3_MAINT_RANGE_ADDR		(1U << 3)
+#define L3_MAINT_TYPE_MASK		GENMASK(2, 1)
+#define L3_MAINT_TYPE_CLEAN		(1U << 1)
+#define L3_MAINT_TYPE_INV		(2U << 1)
+#define L3_MAINT_TYPE_FLUSH		(3U << 1)
+#define L3_MAINT_STATUS_MASK		GENMASK(0, 0)
+#define L3_MAINT_STATUS_START		(1U << 0)
+#define L3_MAINT_STATUS_END		(0U << 0)
+
+#define L3_MAINT_START			0x24
+#define L3_MAINT_END			0x28
+
+#endif
-- 
2.26.0.106.g9fadedd

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Arnd Bergmann]

On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:

> +---
> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Hisilicon L3 cache controller
> +
> +maintainers:
> +  - Wei Xu <xuwei5@hisilicon.com>
> +
> +description: |
> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
> +  addresses. The data cached in the L3 outer cache can be operated based on the
> +  physical address range or the entire cache.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: hisilicon,l3cache
> +

The compatible string needs to be a little more specific, I'm sure
you cannot guarantee that this is the only L3 cache controller ever
designed in the past or future by HiSilicon.

Normally when you have an IP block that is itself unnamed but that is specific
to one or a few SoCs but that has no na, the convention is to include the name
of the first SoC that contained it.

Can you share which products actually use this L3 cache controller?

On a related note, what does the memory map look like on this chip?
Do you support more than 4GB of total installed memory? If you
do, this becomes a problem in the future as highmem support
winds down. In fact  anything more than 1GB on a 32-bit system
requires more work on the kernel to be completed before we remove
highmem, and will incur a slowdown. If the total is under 4GB but the
memory is not in a contiguous physical address range. See my
Linaro connect presentation[1] for further information on the topic.

       Arnd

[1] https://connect.linaro.org/resources/lvc20/lvc20-106/

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Leizhen (ThunderTown)]

On 2021/1/12 16:46, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
> 
>> +---
>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Hisilicon L3 cache controller
>> +
>> +maintainers:
>> +  - Wei Xu <xuwei5@hisilicon.com>
>> +
>> +description: |
>> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
>> +  addresses. The data cached in the L3 outer cache can be operated based on the
>> +  physical address range or the entire cache.
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - const: hisilicon,l3cache
>> +
> 
> The compatible string needs to be a little more specific, I'm sure
> you cannot guarantee that this is the only L3 cache controller ever
> designed in the past or future by HiSilicon.
> 
> Normally when you have an IP block that is itself unnamed but that is specific
> to one or a few SoCs but that has no na, the convention is to include the name
> of the first SoC that contained it.

Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
and "hisilicon,hi1215-l3cache".

> 
> Can you share which products actually use this L3 cache controller?

This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where
these two boards are used. Our company is too large. Software is delivered level
by level. I'm only involved in the Kernel-related part.

> 
> On a related note, what does the memory map look like on this chip?

memory@a00000 {
     device_type = "memory";
     reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>;
};

Currently, the DTS is being maintained by ourselves, I'll try to upstream it later.

> Do you support more than 4GB of total installed memory? If you

Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits.

> do, this becomes a problem in the future as highmem support
> winds down. In fact  anything more than 1GB on a 32-bit system
> requires more work on the kernel to be completed before we remove
> highmem, and will incur a slowdown. If the total is under 4GB but the
> memory is not in a contiguous physical address range. See my
> Linaro connect presentation[1] for further information on the topic.

Great.

> 
>        Arnd
> 
> [1] https://connect.linaro.org/resources/lvc20/lvc20-106/
> 
> .
> 

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Arnd Bergmann]

On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
<thunder.leizhen@huawei.com> wrote:
> On 2021/1/12 16:46, Arnd Bergmann wrote:
> > On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >
> >> +---
> >> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Hisilicon L3 cache controller
> >> +
> >> +maintainers:
> >> +  - Wei Xu <xuwei5@hisilicon.com>
> >> +
> >> +description: |
> >> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
> >> +  addresses. The data cached in the L3 outer cache can be operated based on the
> >> +  physical address range or the entire cache.
> >> +
> >> +properties:
> >> +  compatible:
> >> +    items:
> >> +      - const: hisilicon,l3cache
> >> +
> >
> > The compatible string needs to be a little more specific, I'm sure
> > you cannot guarantee that this is the only L3 cache controller ever
> > designed in the past or future by HiSilicon.
> >
> > Normally when you have an IP block that is itself unnamed but that is specific
> > to one or a few SoCs but that has no na, the convention is to include the name
> > of the first SoC that contained it.
>
> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
> and "hisilicon,hi1215-l3cache".

Sounds good.

> > Can you share which products actually use this L3 cache controller?
>
> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where
> these two boards are used. Our company is too large. Software is delivered level
> by level. I'm only involved in the Kernel-related part.
>
> >
> > On a related note, what does the memory map look like on this chip?
>
> memory@a00000 {
>      device_type = "memory";
>      reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>;
> };
>
> Currently, the DTS is being maintained by ourselves, I'll try to upstream it later.
>
> > Do you support more than 4GB of total installed memory? If you
>
> Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits.

Ok, so it appears that the memory is actually contiguous in the first
3.5GB (with a few holes), plus the remaining 0.5GB being offset in
the physical memory by 4GB (starting at 0x1e0000000 instead of
0xe0000000), presumably to allow the use of 32-bit DMA addresses.

This works fine for the moment, but it does require support for
a nonlinear virt_to_phys()/phys_to_virt() translation after highmem
gets removed, and you would get at most 3.75GB anyway, so it
might be easier at that point to just drop the entire last block at
0x1e0000000, but this will depend on how well we get the 4G:4G
code to work, and whether the users will still need kernel updates for
this platform then.

     Arnd

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Leizhen (ThunderTown)]

On 2021/1/12 21:55, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
> <thunder.leizhen@huawei.com> wrote:
>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>
>>>> +---
>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Hisilicon L3 cache controller
>>>> +
>>>> +maintainers:
>>>> +  - Wei Xu <xuwei5@hisilicon.com>
>>>> +
>>>> +description: |
>>>> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
>>>> +  addresses. The data cached in the L3 outer cache can be operated based on the
>>>> +  physical address range or the entire cache.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    items:
>>>> +      - const: hisilicon,l3cache
>>>> +
>>>
>>> The compatible string needs to be a little more specific, I'm sure
>>> you cannot guarantee that this is the only L3 cache controller ever
>>> designed in the past or future by HiSilicon.
>>>
>>> Normally when you have an IP block that is itself unnamed but that is specific
>>> to one or a few SoCs but that has no na, the convention is to include the name
>>> of the first SoC that contained it.
>>
>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
>> and "hisilicon,hi1215-l3cache".

Sorry, Just received a response from the hardware developers, the SoC names need to
be changed:
hi1381 --> kunpeng509
hi1215 --> kunpeng506

So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3
cache controller version 1. This is enough to distinguish other versions of cache
controller. It also facilitates the naming of the config option and files.

> 
> Sounds good.
> 
>>> Can you share which products actually use this L3 cache controller?
>>
>> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where
>> these two boards are used. Our company is too large. Software is delivered level
>> by level. I'm only involved in the Kernel-related part.
>>
>>>
>>> On a related note, what does the memory map look like on this chip?
>>
>> memory@a00000 {
>>      device_type = "memory";
>>      reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>;
>> };
>>
>> Currently, the DTS is being maintained by ourselves, I'll try to upstream it later.
>>
>>> Do you support more than 4GB of total installed memory? If you
>>
>> Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits.
> 
> Ok, so it appears that the memory is actually contiguous in the first
> 3.5GB (with a few holes), plus the remaining 0.5GB being offset in
> the physical memory by 4GB (starting at 0x1e0000000 instead of
> 0xe0000000), presumably to allow the use of 32-bit DMA addresses.
> 
> This works fine for the moment, but it does require support for
> a nonlinear virt_to_phys()/phys_to_virt() translation after highmem
> gets removed, and you would get at most 3.75GB anyway, so it
> might be easier at that point to just drop the entire last block at
> 0x1e0000000, but this will depend on how well we get the 4G:4G
> code to work, and whether the users will still need kernel updates for
> this platform then.>
>      Arnd
> 
> .
> 

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Leizhen (ThunderTown)]

On 2021/1/13 15:44, Leizhen (ThunderTown) wrote:
> 
> 
> On 2021/1/12 21:55, Arnd Bergmann wrote:
>> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
>> <thunder.leizhen@huawei.com> wrote:
>>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Hisilicon L3 cache controller
>>>>> +
>>>>> +maintainers:
>>>>> +  - Wei Xu <xuwei5@hisilicon.com>
>>>>> +
>>>>> +description: |
>>>>> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
>>>>> +  addresses. The data cached in the L3 outer cache can be operated based on the
>>>>> +  physical address range or the entire cache.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    items:
>>>>> +      - const: hisilicon,l3cache
>>>>> +
>>>>
>>>> The compatible string needs to be a little more specific, I'm sure
>>>> you cannot guarantee that this is the only L3 cache controller ever
>>>> designed in the past or future by HiSilicon.
>>>>
>>>> Normally when you have an IP block that is itself unnamed but that is specific
>>>> to one or a few SoCs but that has no na, the convention is to include the name
>>>> of the first SoC that contained it.
>>>
>>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
>>> and "hisilicon,hi1215-l3cache".
> 
> Sorry, Just received a response from the hardware developers, the SoC names need to
> be changed:
> hi1381 --> kunpeng509
> hi1215 --> kunpeng506
> 
> So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3

I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in
the future. Maybe the SoC name is changed later, and v2 is not required.

> cache controller version 1. This is enough to distinguish other versions of cache
> controller. It also facilitates the naming of the config option and files.
> 
>>
>> Sounds good.
>>
>>>> Can you share which products actually use this L3 cache controller?
>>>
>>> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know where
>>> these two boards are used. Our company is too large. Software is delivered level
>>> by level. I'm only involved in the Kernel-related part.
>>>
>>>>
>>>> On a related note, what does the memory map look like on this chip?
>>>
>>> memory@a00000 {
>>>      device_type = "memory";
>>>      reg = <0x0 0xa00000 0x0 0x1aa00000>, <0x1 0xe0000000 0x0 0x1d000000>, <0x0 0x1f400000 0x0 0xb5c00000>;
>>> };
>>>
>>> Currently, the DTS is being maintained by ourselves, I'll try to upstream it later.
>>>
>>>> Do you support more than 4GB of total installed memory? If you
>>>
>>> Currently, the total size does not exceed 4 GB. However, the physical address is wider than 32 bits.
>>
>> Ok, so it appears that the memory is actually contiguous in the first
>> 3.5GB (with a few holes), plus the remaining 0.5GB being offset in
>> the physical memory by 4GB (starting at 0x1e0000000 instead of
>> 0xe0000000), presumably to allow the use of 32-bit DMA addresses.
>>
>> This works fine for the moment, but it does require support for
>> a nonlinear virt_to_phys()/phys_to_virt() translation after highmem
>> gets removed, and you would get at most 3.75GB anyway, so it
>> might be easier at that point to just drop the entire last block at
>> 0x1e0000000, but this will depend on how well we get the 4G:4G
>> code to work, and whether the users will still need kernel updates for
>> this platform then.>
>>      Arnd
>>
>> .
>>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> .
> 

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Arnd Bergmann]

On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown)
<thunder.leizhen@huawei.com> wrote:
> On 2021/1/13 15:44, Leizhen (ThunderTown) wrote:
> > On 2021/1/12 21:55, Arnd Bergmann wrote:
> >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
> >> <thunder.leizhen@huawei.com> wrote:
> >>> On 2021/1/12 16:46, Arnd Bergmann wrote:
> >>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >>>>
> >>>>> +---
> >>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
> >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>> +
> >>>>> +title: Hisilicon L3 cache controller
> >>>>> +
> >>>>> +maintainers:
> >>>>> +  - Wei Xu <xuwei5@hisilicon.com>
> >>>>> +
> >>>>> +description: |
> >>>>> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
> >>>>> +  addresses. The data cached in the L3 outer cache can be operated based on the
> >>>>> +  physical address range or the entire cache.
> >>>>> +
> >>>>> +properties:
> >>>>> +  compatible:
> >>>>> +    items:
> >>>>> +      - const: hisilicon,l3cache
> >>>>> +
> >>>>
> >>>> The compatible string needs to be a little more specific, I'm sure
> >>>> you cannot guarantee that this is the only L3 cache controller ever
> >>>> designed in the past or future by HiSilicon.
> >>>>
> >>>> Normally when you have an IP block that is itself unnamed but that is specific
> >>>> to one or a few SoCs but that has no na, the convention is to include the name
> >>>> of the first SoC that contained it.
> >>>
> >>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
> >>> and "hisilicon,hi1215-l3cache".
> >
> > Sorry, Just received a response from the hardware developers, the SoC names need to
> > be changed:
> > hi1381 --> kunpeng509
> > hi1215 --> kunpeng506
> >
> > So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3
>
> I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in
> the future. Maybe the SoC name is changed later, and v2 is not required.

I would prefer the more specific name to be listed as well. You can
use the generic
"hisilicon,kunpeng-l3cache" as the key that the driver uses, but
please also include
the chip specific one here. We tend to use the chip identifiers
(hi1381, ...), but if
the marketing names (kunpeng509, ...) are now what they are known as in the
data sheet, then use that. The problem with marketing names is that they are
more often unrelated to the technology underneath. It's possible that there
might be e.g. kunpeng507 chip that sold to the same customers but very different
internally from kunpeng506/kunpeng509. This also happens with the chip numbers,
but those tend to be more stable (at least for other manufacturers).

       Arnd

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

[Leizhen (ThunderTown)]

On 2021/1/13 19:15, Arnd Bergmann wrote:
> On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown)
> <thunder.leizhen@huawei.com> wrote:
>> On 2021/1/13 15:44, Leizhen (ThunderTown) wrote:
>>> On 2021/1/12 21:55, Arnd Bergmann wrote:
>>>> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
>>>> <thunder.leizhen@huawei.com> wrote:
>>>>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>>>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>>
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Hisilicon L3 cache controller
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Wei Xu <xuwei5@hisilicon.com>
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +  The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical
>>>>>>> +  addresses. The data cached in the L3 outer cache can be operated based on the
>>>>>>> +  physical address range or the entire cache.
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    items:
>>>>>>> +      - const: hisilicon,l3cache
>>>>>>> +
>>>>>>
>>>>>> The compatible string needs to be a little more specific, I'm sure
>>>>>> you cannot guarantee that this is the only L3 cache controller ever
>>>>>> designed in the past or future by HiSilicon.
>>>>>>
>>>>>> Normally when you have an IP block that is itself unnamed but that is specific
>>>>>> to one or a few SoCs but that has no na, the convention is to include the name
>>>>>> of the first SoC that contained it.
>>>>>
>>>>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache"
>>>>> and "hisilicon,hi1215-l3cache".
>>>
>>> Sorry, Just received a response from the hardware developers, the SoC names need to
>>> be changed:
>>> hi1381 --> kunpeng509
>>> hi1215 --> kunpeng506
>>>
>>> So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3
>>
>> I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in
>> the future. Maybe the SoC name is changed later, and v2 is not required.
> 
> I would prefer the more specific name to be listed as well. You can
> use the generic
> "hisilicon,kunpeng-l3cache" as the key that the driver uses, but
> please also include
> the chip specific one here.

Oh, yes. Sometimes, the "syscon" is used this way . The first string describes
the component information，and the second string is used to match the driver.

compatible = "hisilicon,kunpeng506-l3cache", "hisilicon,kunpeng-l3cache"


> We tend to use the chip identifiers
> (hi1381, ...), but if
> the marketing names (kunpeng509, ...) are now what they are known as in the

The hardware developers told me that hi1381 is the internal chip identifier,
and should be deprecated. kunpeng509 is both chip identifier and marketing name.

Kunpeng is the pinyin of two Chinese characters. They are two mythical animals.

> data sheet, then use that. The problem with marketing names is that they are
> more often unrelated to the technology underneath. It's possible that there
> might be e.g. kunpeng507 chip that sold to the same customers but very different
> internally from kunpeng506/kunpeng509. This also happens with the chip numbers,

It shouldn't make a big difference，unless the first two numbers are different.

> but those tend to be more stable (at least for other manufacturers).
> 
>        Arnd
> 
> .
>