Linux-EDAC Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR
@ 2019-07-12  3:48 Chris Packham
  2019-07-12  3:48 ` [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE Chris Packham
                   ` (8 more replies)
  0 siblings, 9 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:48 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel, Chris Packham

Hi,

I still seem to be struggling to get this on anyone's radar.

The Reviews/Acks have been given so this should be good to go in via the ARM
tree as planned.

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

This series adds drivers for the L2 cache and DDR RAM ECC functionality as
found on the MV78230/MV78x60 SoCs. Jan has tested these changes with the
MV78460 (on a custom board with a DDR3 ECC DIMM), Chris has tested these
changes with 88F6820 and 98dx3236 (both a custom boards with fixed DDR3 + ECC).

Also contained in this series is an additional debugfs wrapper.

Compared to the previous v8 series this has been rebased against
v5.2-5628-g753c8d9b7d81 to avoid some conflicts related to debugfs API changes.

Compared to the previous v7 series this has been rebased against 5.1 requiring
some changes in the devicetree binding documentation.

Compared to the previous v6 series I've dropped the marvell,ecc-disable
property.

Compared to the previous v5 series I've split the dt-binding documentation into
its own patch and updated armada_xp_edac.c to use a SPDX license.

Compared to the previous v4 series I've added my s-o-b to some of Jan's
patches and rebased against v4.19.0.

Compared to the previous v3 series, the following changes have been made:
- Use shorter names for the AURORA ECC and parity registers
- Numerous formatting changes to edac/armada_xp.c (as requested by Boris)
- Added support for Armada-38x and 98dx3236 SoCs

Compared to the previous v2 series, the following changes have been made:
- Allocate EDAC structures later during probing and drop devres support
  patches (requested by Boris)
- Make drvdata->width usage consistent according to the comment (suggested by
  Chris)

Compared to the previous v1 series, the following changes have been made:
- Add the aurora-l2 register defines earlier in the series (suggested by
  Russell King and Gregory CLEMENT )
- Changed the DT vendor prefix from "arm" to "marvell" for the ecc-enable/disable
  properties on the aurora-l2 (suggested by Russell King)
- Fix some warnings reported by checkpatch

Compared to the original RFC series, the following changes have been made:
- Integrated Chris' patches for parity and ECC configuration via DT
- Merged the DDR RAM and L2 cache drivers (as requested by Boris, analogous
  to fsl_ddr_edac.c and mpc85xx_edac.c)
- Added myself to MAINTAINERS (requested by Boris)
- L2 cache: Track the msg size and use snprintf (review comment by Chris)
- L2 cache: Split error injection from the check function (review comment by
  Chris)
- DDR RAM: Allow 16 bit width in addition to 32 and 64 bit (review comment by
  Chris)
- Use of_match_ptr() (review comments by Chris)
- Minor checkpatch cleanups


Chris Packham (4):
  ARM: l2x0: support parity-enable/disable on aurora
  dt-bindings: ARM: document marvell,ecc-enable binding
  ARM: l2x0: add marvell,ecc-enable property for aurora
  EDAC: armada_xp: Add support for more SoCs

Jan Luebbe (4):
  ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  ARM: aurora-l2: add defines for parity and ECC registers
  EDAC: Add missing debugfs_create_x32 wrapper
  EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

 .../devicetree/bindings/arm/l2c2x0.yaml       |   4 +
 MAINTAINERS                                   |   6 +
 .../include/asm/hardware/cache-aurora-l2.h    |  50 +-
 arch/arm/mm/cache-l2x0.c                      |  16 +-
 drivers/edac/Kconfig                          |   7 +
 drivers/edac/Makefile                         |   1 +
 drivers/edac/armada_xp_edac.c                 | 635 ++++++++++++++++++
 drivers/edac/debugfs.c                        |  11 +
 drivers/edac/edac_module.h                    |   4 +
 9 files changed, 731 insertions(+), 3 deletions(-)
 create mode 100644 drivers/edac/armada_xp_edac.c

-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
@ 2019-07-12  3:48 ` Chris Packham
  2019-08-23 10:46   ` Russell King - ARM Linux admin
  2019-07-12  3:48 ` [PATCH v9 2/8] ARM: aurora-l2: add defines for parity and ECC registers Chris Packham
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:48 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Gregory CLEMENT, Chris Packham

From: Jan Luebbe <jlu@pengutronix.de>

The macro name is too generic, so add a AURORA_ prefix.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
 arch/arm/mm/cache-l2x0.c                        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index c86124769831..dc5c479ec4c3 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -41,7 +41,7 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY	\
 	(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
-#define MAX_RANGE_SIZE		1024
+#define AURORA_MAX_RANGE_SIZE	1024
 
 #define AURORA_WAY_SIZE_SHIFT	2
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 428d08718107..83b733a1f1e6 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
 	 * since cache range operations stall the CPU pipeline
 	 * until completion.
 	 */
-	if (end > start + MAX_RANGE_SIZE)
-		end = start + MAX_RANGE_SIZE;
+	if (end > start + AURORA_MAX_RANGE_SIZE)
+		end = start + AURORA_MAX_RANGE_SIZE;
 
 	/*
 	 * Cache range operations can't straddle a page boundary.
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 2/8] ARM: aurora-l2: add defines for parity and ECC registers
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
  2019-07-12  3:48 ` [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE Chris Packham
@ 2019-07-12  3:48 ` Chris Packham
  2019-07-12  3:48 ` [PATCH v9 3/8] ARM: l2x0: support parity-enable/disable on aurora Chris Packham
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:48 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel, Chris Packham

From: Jan Luebbe <jlu@pengutronix.de>

These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 .../include/asm/hardware/cache-aurora-l2.h    | 48 +++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index dc5c479ec4c3..39769ffa0051 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -31,6 +31,9 @@
 #define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
 	(3 << AURORA_ACR_REPLACEMENT_OFFSET)
 
+#define AURORA_ACR_PARITY_EN	(1 << 21)
+#define AURORA_ACR_ECC_EN	(1 << 20)
+
 #define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET	0
 #define AURORA_ACR_FORCE_WRITE_POLICY_MASK	\
 	(0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
@@ -41,6 +44,51 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY	\
 	(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
+#define AURORA_ERR_CNT_REG          0x600
+#define AURORA_ERR_ATTR_CAP_REG     0x608
+#define AURORA_ERR_ADDR_CAP_REG     0x60c
+#define AURORA_ERR_WAY_CAP_REG      0x610
+#define AURORA_ERR_INJECT_CTL_REG   0x614
+#define AURORA_ERR_INJECT_MASK_REG  0x618
+
+#define AURORA_ERR_CNT_CLR_OFFSET         31
+#define AURORA_ERR_CNT_CLR		   \
+	(0x1 << AURORA_ERR_CNT_CLR_OFFSET)
+#define AURORA_ERR_CNT_UE_OFFSET          16
+#define AURORA_ERR_CNT_UE_MASK             \
+	(0x7fff << AURORA_ERR_CNT_UE_OFFSET)
+#define AURORA_ERR_CNT_CE_OFFSET           0
+#define AURORA_ERR_CNT_CE_MASK             \
+	(0xffff << AURORA_ERR_CNT_CE_OFFSET)
+
+#define AURORA_ERR_ATTR_SRC_OFF           16
+#define AURORA_ERR_ATTR_SRC_MSK            \
+	(0x7 << AURORA_ERR_ATTR_SRC_OFF)
+#define AURORA_ERR_ATTR_TXN_OFF           12
+#define AURORA_ERR_ATTR_TXN_MSK            \
+	(0xf << AURORA_ERR_ATTR_TXN_OFF)
+#define AURORA_ERR_ATTR_ERR_OFF            8
+#define AURORA_ERR_ATTR_ERR_MSK            \
+	(0x3 << AURORA_ERR_ATTR_ERR_OFF)
+#define AURORA_ERR_ATTR_CAP_VALID_OFF      0
+#define AURORA_ERR_ATTR_CAP_VALID          \
+	(0x1 << AURORA_ERR_ATTR_CAP_VALID_OFF)
+
+#define AURORA_ERR_ADDR_CAP_ADDR_MASK 0xffffffe0
+
+#define AURORA_ERR_WAY_IDX_OFF             8
+#define AURORA_ERR_WAY_IDX_MSK             \
+	(0xfff << AURORA_ERR_WAY_IDX_OFF)
+#define AURORA_ERR_WAY_CAP_WAY_OFFSET      1
+#define AURORA_ERR_WAY_CAP_WAY_MASK        \
+	(0xf << AURORA_ERR_WAY_CAP_WAY_OFFSET)
+
+#define AURORA_ERR_INJECT_CTL_ADDR_MASK 0xfffffff0
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_INJECT_CTL_EN_MASK          0x3
+#define AURORA_ERR_INJECT_CTL_EN_PARITY        0x2
+#define AURORA_ERR_INJECT_CTL_EN_ECC           0x1
+
 #define AURORA_MAX_RANGE_SIZE	1024
 
 #define AURORA_WAY_SIZE_SHIFT	2
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 3/8] ARM: l2x0: support parity-enable/disable on aurora
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
  2019-07-12  3:48 ` [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE Chris Packham
  2019-07-12  3:48 ` [PATCH v9 2/8] ARM: aurora-l2: add defines for parity and ECC registers Chris Packham
@ 2019-07-12  3:48 ` Chris Packham
  2019-07-12  3:49 ` [PATCH v9 4/8] dt-bindings: ARM: document marvell,ecc-enable binding Chris Packham
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:48 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel, Chris Packham

The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[jlu@pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
---
 arch/arm/mm/cache-l2x0.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 83b733a1f1e6..46a616ec6b0c 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1493,6 +1493,13 @@ static void __init aurora_of_parse(const struct device_node *np,
 		mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
 	}
 
+	if (of_property_read_bool(np, "arm,parity-enable")) {
+		mask |= AURORA_ACR_PARITY_EN;
+		val |= AURORA_ACR_PARITY_EN;
+	} else if (of_property_read_bool(np, "arm,parity-disable")) {
+		mask |= AURORA_ACR_PARITY_EN;
+	}
+
 	*aux_val &= ~mask;
 	*aux_val |= val;
 	*aux_mask &= ~mask;
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 4/8] dt-bindings: ARM: document marvell,ecc-enable binding
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (2 preceding siblings ...)
  2019-07-12  3:48 ` [PATCH v9 3/8] ARM: l2x0: support parity-enable/disable on aurora Chris Packham
@ 2019-07-12  3:49 ` Chris Packham
  2019-07-12  3:49 ` [PATCH v9 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora Chris Packham
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:49 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Chris Packham, Rob Herring

Add documentation for the marvell,ecc-enable properties which can be
used to enable ECC on the Marvell aurora cache.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Rob Herring <robh@kernel.org>
---

Notes:
    Changes in v7:
    - remove marvell,ecc-disable
    Changes in v6:
    - new (split binding doc from implementation).

 Documentation/devicetree/bindings/arm/l2c2x0.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.yaml b/Documentation/devicetree/bindings/arm/l2c2x0.yaml
index bfc5c185561c..913a8cd8b2c0 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.yaml
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.yaml
@@ -176,6 +176,10 @@ properties:
     description: disable parity checking on the L2 cache (L220 or PL310).
     type: boolean
 
+  marvell,ecc-enable:
+    description: enable ECC protection on the L2 cache
+    type: boolean
+
   arm,outer-sync-disable:
     description: disable the outer sync operation on the L2 cache.
       Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (3 preceding siblings ...)
  2019-07-12  3:49 ` [PATCH v9 4/8] dt-bindings: ARM: document marvell,ecc-enable binding Chris Packham
@ 2019-07-12  3:49 ` Chris Packham
  2019-07-12  3:49 ` [PATCH v9 6/8] EDAC: Add missing debugfs_create_x32 wrapper Chris Packham
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:49 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel, Chris Packham

The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[jlu@pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
---

Notes:
    Changes in v7:
    - remove marvell,ecc-disable

 arch/arm/mm/cache-l2x0.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 46a616ec6b0c..12c26eb88afb 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1493,6 +1493,11 @@ static void __init aurora_of_parse(const struct device_node *np,
 		mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
 	}
 
+	if (of_property_read_bool(np, "marvell,ecc-enable")) {
+		mask |= AURORA_ACR_ECC_EN;
+		val |= AURORA_ACR_ECC_EN;
+	}
+
 	if (of_property_read_bool(np, "arm,parity-enable")) {
 		mask |= AURORA_ACR_PARITY_EN;
 		val |= AURORA_ACR_PARITY_EN;
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 6/8] EDAC: Add missing debugfs_create_x32 wrapper
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (4 preceding siblings ...)
  2019-07-12  3:49 ` [PATCH v9 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora Chris Packham
@ 2019-07-12  3:49 ` Chris Packham
  2019-07-12  3:49 ` [PATCH v9 7/8] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC Chris Packham
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:49 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Borislav Petkov, Chris Packham

From: Jan Luebbe <jlu@pengutronix.de>

We already have wrappers for x8 and x16, so add the missing x32 one.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---

Notes:
    Changes in v9:
    - Adapt debugfs_create_x32 to account for recent changes to debugfs apis

 drivers/edac/debugfs.c     | 11 +++++++++++
 drivers/edac/edac_module.h |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
index 1f943599a8ac..4804332d9946 100644
--- a/drivers/edac/debugfs.c
+++ b/drivers/edac/debugfs.c
@@ -138,3 +138,14 @@ void edac_debugfs_create_x16(const char *name, umode_t mode,
 	debugfs_create_x16(name, mode, parent, value);
 }
 EXPORT_SYMBOL_GPL(edac_debugfs_create_x16);
+
+/* Wrapper for debugfs_create_x32() */
+void edac_debugfs_create_x32(const char *name, umode_t mode,
+			     struct dentry *parent, u32 *value)
+{
+	if (!parent)
+		parent = edac_debugfs;
+
+	debugfs_create_x32(name, mode, parent, value);
+}
+EXPORT_SYMBOL_GPL(edac_debugfs_create_x32);
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index b2f59ee76c22..388427d378b1 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -82,6 +82,8 @@ void edac_debugfs_create_x8(const char *name, umode_t mode,
 			    struct dentry *parent, u8 *value);
 void edac_debugfs_create_x16(const char *name, umode_t mode,
 			     struct dentry *parent, u16 *value);
+void edac_debugfs_create_x32(const char *name, umode_t mode,
+			     struct dentry *parent, u32 *value);
 #else
 static inline void edac_debugfs_init(void)					{ }
 static inline void edac_debugfs_exit(void)					{ }
@@ -96,6 +98,8 @@ static inline void edac_debugfs_create_x8(const char *name, umode_t mode,
 					  struct dentry *parent, u8 *value)	{ }
 static inline void edac_debugfs_create_x16(const char *name, umode_t mode,
 					   struct dentry *parent, u16 *value)	{ }
+static inline void edac_debugfs_create_x32(const char *name, umode_t mode,
+		       struct dentry *parent, u32 *value)			{ }
 #endif
 
 /*
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 7/8] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (5 preceding siblings ...)
  2019-07-12  3:49 ` [PATCH v9 6/8] EDAC: Add missing debugfs_create_x32 wrapper Chris Packham
@ 2019-07-12  3:49 ` Chris Packham
  2019-07-12  3:49 ` [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs Chris Packham
  2019-07-26 14:53 ` [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR James Morse
  8 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:49 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Chris Packham, Borislav Petkov

From: Jan Luebbe <jlu@pengutronix.de>

Add support for the ECC functionality as found in the DDR RAM and L2
cache controllers on the MV78230/MV78x60 SoCs. This driver has been
tested on the MV78460 (on a custom board with a DDR3 ECC DIMM).

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
[cp use SPDX license]
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Borislav Petkov <bp@suse.de>
---
 MAINTAINERS                   |   6 +
 drivers/edac/Kconfig          |   7 +
 drivers/edac/Makefile         |   1 +
 drivers/edac/armada_xp_edac.c | 630 ++++++++++++++++++++++++++++++++++
 4 files changed, 644 insertions(+)
 create mode 100644 drivers/edac/armada_xp_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 618e4979960b..d6cf0771c998 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5697,6 +5697,12 @@ L:	linux-edac@vger.kernel.org
 S:	Maintained
 F:	drivers/edac/amd64_edac*
 
+EDAC-ARMADA
+M:	Jan Luebbe <jlu@pengutronix.de>
+L:	linux-edac@vger.kernel.org
+S:	Maintained
+F:	drivers/edac/armada_xp_*
+
 EDAC-AST2500
 M:	Stefan Schaeckeler <sschaeck@cisco.com>
 S:	Supported
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 200c04ce5b0e..39c58b37b889 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -466,6 +466,13 @@ config EDAC_SIFIVE
 	help
 	  Support for error detection and correction on the SiFive SoCs.
 
+config EDAC_ARMADA_XP
+	bool "Marvell Armada XP DDR and L2 Cache ECC"
+	depends on MACH_MVEBU_V7
+	help
+	  Support for error correction and detection on the Marvell Aramada XP
+	  DDR RAM and L2 cache controllers.
+
 config EDAC_SYNOPSYS
 	tristate "Synopsys DDR Memory Controller"
 	depends on ARCH_ZYNQ || ARCH_ZYNQMP
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 165ca65e1a3a..7b6348339a3b 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_EDAC_THUNDERX)		+= thunderx_edac.o
 
 obj-$(CONFIG_EDAC_ALTERA)		+= altera_edac.o
 obj-$(CONFIG_EDAC_SIFIVE)		+= sifive_edac.o
+obj-$(CONFIG_EDAC_ARMADA_XP)		+= armada_xp_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)		+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)		+= xgene_edac.o
 obj-$(CONFIG_EDAC_TI)			+= ti_edac.o
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
new file mode 100644
index 000000000000..3759a4fbbdee
--- /dev/null
+++ b/drivers/edac/armada_xp_edac.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Pengutronix, Jan Luebbe <kernel@pengutronix.de>
+ */
+
+#include <linux/kernel.h>
+#include <linux/edac.h>
+#include <linux/of_platform.h>
+
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/hardware/cache-aurora-l2.h>
+
+#include "edac_mc.h"
+#include "edac_device.h"
+#include "edac_module.h"
+
+/************************ EDAC MC (DDR RAM) ********************************/
+
+#define SDRAM_NUM_CS 4
+
+#define SDRAM_CONFIG_REG        0x0
+#define SDRAM_CONFIG_ECC_MASK         BIT(18)
+#define SDRAM_CONFIG_REGISTERED_MASK  BIT(17)
+#define SDRAM_CONFIG_BUS_WIDTH_MASK   BIT(15)
+
+#define SDRAM_ADDR_CTRL_REG     0x10
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs) (20+cs)
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_MASK(cs)   (0x1 << SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_ADDR_SEL_MASK(cs)    BIT(16+cs)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs)  (cs*4+2)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_MASK(cs)    (0x3 << SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs)    (cs*4)
+#define SDRAM_ADDR_CTRL_STRUCT_MASK(cs)      (0x3 << SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs))
+
+#define SDRAM_ERR_DATA_H_REG    0x40
+#define SDRAM_ERR_DATA_L_REG    0x44
+
+#define SDRAM_ERR_RECV_ECC_REG  0x48
+#define SDRAM_ERR_RECV_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_CALC_ECC_REG  0x4c
+#define SDRAM_ERR_CALC_ECC_ROW_OFFSET 8
+#define SDRAM_ERR_CALC_ECC_ROW_MASK   (0xffff << SDRAM_ERR_CALC_ECC_ROW_OFFSET)
+#define SDRAM_ERR_CALC_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_ADDR_REG      0x50
+#define SDRAM_ERR_ADDR_BANK_OFFSET    23
+#define SDRAM_ERR_ADDR_BANK_MASK      (0x7 << SDRAM_ERR_ADDR_BANK_OFFSET)
+#define SDRAM_ERR_ADDR_COL_OFFSET     8
+#define SDRAM_ERR_ADDR_COL_MASK       (0x7fff << SDRAM_ERR_ADDR_COL_OFFSET)
+#define SDRAM_ERR_ADDR_CS_OFFSET      1
+#define SDRAM_ERR_ADDR_CS_MASK        (0x3 << SDRAM_ERR_ADDR_CS_OFFSET)
+#define SDRAM_ERR_ADDR_TYPE_MASK      BIT(0)
+
+#define SDRAM_ERR_CTRL_REG      0x54
+#define SDRAM_ERR_CTRL_THR_OFFSET     16
+#define SDRAM_ERR_CTRL_THR_MASK       (0xff << SDRAM_ERR_CTRL_THR_OFFSET)
+#define SDRAM_ERR_CTRL_PROP_MASK      BIT(9)
+
+#define SDRAM_ERR_SBE_COUNT_REG 0x58
+#define SDRAM_ERR_DBE_COUNT_REG 0x5c
+
+#define SDRAM_ERR_CAUSE_ERR_REG 0xd0
+#define SDRAM_ERR_CAUSE_MSG_REG 0xd8
+#define SDRAM_ERR_CAUSE_DBE_MASK      BIT(1)
+#define SDRAM_ERR_CAUSE_SBE_MASK      BIT(0)
+
+#define SDRAM_RANK_CTRL_REG 0x1e0
+#define SDRAM_RANK_CTRL_EXIST_MASK(cs) BIT(cs)
+
+struct axp_mc_drvdata {
+	void __iomem *base;
+	/* width in bytes */
+	unsigned int width;
+	/* bank interleaving */
+	bool cs_addr_sel[SDRAM_NUM_CS];
+
+	char msg[128];
+};
+
+/* derived from "DRAM Address Multiplexing" in the ARAMDA XP Functional Spec */
+static uint32_t axp_mc_calc_address(struct axp_mc_drvdata *drvdata,
+				    uint8_t cs, uint8_t bank, uint16_t row,
+				    uint16_t col)
+{
+	if (drvdata->width == 8) {
+		/* 64 bit */
+		if (drvdata->cs_addr_sel[cs])
+			/* bank interleaved */
+			return (((row & 0xfff8) << 16) |
+				((bank & 0x7) << 16) |
+				((row & 0x7) << 13) |
+				((col & 0x3ff) << 3));
+		else
+			return (((row & 0xffff << 16) |
+				 ((bank & 0x7) << 13) |
+				 ((col & 0x3ff)) << 3));
+	} else if (drvdata->width == 4) {
+		/* 32 bit */
+		if (drvdata->cs_addr_sel[cs])
+			/* bank interleaved */
+			return (((row & 0xfff0) << 15) |
+				((bank & 0x7) << 16) |
+				((row & 0xf) << 12) |
+				((col & 0x3ff) << 2));
+		else
+			return (((row & 0xffff << 15) |
+				 ((bank & 0x7) << 12) |
+				 ((col & 0x3ff)) << 2));
+	} else {
+		/* 16 bit */
+		if (drvdata->cs_addr_sel[cs])
+			/* bank interleaved */
+			return (((row & 0xffe0) << 14) |
+				((bank & 0x7) << 16) |
+				((row & 0x1f) << 11) |
+				((col & 0x3ff) << 1));
+		else
+			return (((row & 0xffff << 14) |
+				 ((bank & 0x7) << 11) |
+				 ((col & 0x3ff)) << 1));
+	}
+}
+
+static void axp_mc_check(struct mem_ctl_info *mci)
+{
+	struct axp_mc_drvdata *drvdata = mci->pvt_info;
+	uint32_t data_h, data_l, recv_ecc, calc_ecc, addr;
+	uint32_t cnt_sbe, cnt_dbe, cause_err, cause_msg;
+	uint32_t row_val, col_val, bank_val, addr_val;
+	uint8_t syndrome_val, cs_val;
+	char *msg = drvdata->msg;
+
+	data_h    = readl(drvdata->base + SDRAM_ERR_DATA_H_REG);
+	data_l    = readl(drvdata->base + SDRAM_ERR_DATA_L_REG);
+	recv_ecc  = readl(drvdata->base + SDRAM_ERR_RECV_ECC_REG);
+	calc_ecc  = readl(drvdata->base + SDRAM_ERR_CALC_ECC_REG);
+	addr      = readl(drvdata->base + SDRAM_ERR_ADDR_REG);
+	cnt_sbe   = readl(drvdata->base + SDRAM_ERR_SBE_COUNT_REG);
+	cnt_dbe   = readl(drvdata->base + SDRAM_ERR_DBE_COUNT_REG);
+	cause_err = readl(drvdata->base + SDRAM_ERR_CAUSE_ERR_REG);
+	cause_msg = readl(drvdata->base + SDRAM_ERR_CAUSE_MSG_REG);
+
+	/* clear cause registers */
+	writel(~(SDRAM_ERR_CAUSE_DBE_MASK | SDRAM_ERR_CAUSE_SBE_MASK),
+	       drvdata->base + SDRAM_ERR_CAUSE_ERR_REG);
+	writel(~(SDRAM_ERR_CAUSE_DBE_MASK | SDRAM_ERR_CAUSE_SBE_MASK),
+	       drvdata->base + SDRAM_ERR_CAUSE_MSG_REG);
+
+	/* clear error counter registers */
+	if (cnt_sbe)
+		writel(0, drvdata->base + SDRAM_ERR_SBE_COUNT_REG);
+	if (cnt_dbe)
+		writel(0, drvdata->base + SDRAM_ERR_DBE_COUNT_REG);
+
+	if (!cnt_sbe && !cnt_dbe)
+		return;
+
+	if (!(addr & SDRAM_ERR_ADDR_TYPE_MASK)) {
+		if (cnt_sbe)
+			cnt_sbe--;
+		else
+			dev_warn(mci->pdev, "inconsistent SBE count detected");
+	} else {
+		if (cnt_dbe)
+			cnt_dbe--;
+		else
+			dev_warn(mci->pdev, "inconsistent DBE count detected");
+	}
+
+	/* report earlier errors */
+	if (cnt_sbe)
+		edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
+				     cnt_sbe, /* error count */
+				     0, 0, 0, /* pfn, offset, syndrome */
+				     -1, -1, -1, /* top, mid, low layer */
+				     mci->ctl_name,
+				     "details unavailable (multiple errors)");
+	if (cnt_dbe)
+		edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
+				     cnt_sbe, /* error count */
+				     0, 0, 0, /* pfn, offset, syndrome */
+				     -1, -1, -1, /* top, mid, low layer */
+				     mci->ctl_name,
+				     "details unavailable (multiple errors)");
+
+	/* report details for most recent error */
+	cs_val   = (addr & SDRAM_ERR_ADDR_CS_MASK) >> SDRAM_ERR_ADDR_CS_OFFSET;
+	bank_val = (addr & SDRAM_ERR_ADDR_BANK_MASK) >> SDRAM_ERR_ADDR_BANK_OFFSET;
+	row_val  = (calc_ecc & SDRAM_ERR_CALC_ECC_ROW_MASK) >> SDRAM_ERR_CALC_ECC_ROW_OFFSET;
+	col_val  = (addr & SDRAM_ERR_ADDR_COL_MASK) >> SDRAM_ERR_ADDR_COL_OFFSET;
+	syndrome_val = (recv_ecc ^ calc_ecc) & 0xff;
+	addr_val = axp_mc_calc_address(drvdata, cs_val, bank_val, row_val,
+				       col_val);
+	msg += sprintf(msg, "row=0x%04x ", row_val); /* 11 chars */
+	msg += sprintf(msg, "bank=0x%x ", bank_val); /*  9 chars */
+	msg += sprintf(msg, "col=0x%04x ", col_val); /* 11 chars */
+	msg += sprintf(msg, "cs=%d", cs_val);	     /*  4 chars */
+
+	if (!(addr & SDRAM_ERR_ADDR_TYPE_MASK)) {
+		edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
+				     1,	/* error count */
+				     addr_val >> PAGE_SHIFT,
+				     addr_val & ~PAGE_MASK,
+				     syndrome_val,
+				     cs_val, -1, -1, /* top, mid, low layer */
+				     mci->ctl_name, drvdata->msg);
+	} else {
+		edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
+				     1,	/* error count */
+				     addr_val >> PAGE_SHIFT,
+				     addr_val & ~PAGE_MASK,
+				     syndrome_val,
+				     cs_val, -1, -1, /* top, mid, low layer */
+				     mci->ctl_name, drvdata->msg);
+	}
+}
+
+static void axp_mc_read_config(struct mem_ctl_info *mci)
+{
+	struct axp_mc_drvdata *drvdata = mci->pvt_info;
+	uint32_t config, addr_ctrl, rank_ctrl;
+	unsigned int i, cs_struct, cs_size;
+	struct dimm_info *dimm;
+
+	config = readl(drvdata->base + SDRAM_CONFIG_REG);
+	if (config & SDRAM_CONFIG_BUS_WIDTH_MASK)
+		/* 64 bit */
+		drvdata->width = 8;
+	else
+		/* 32 bit */
+		drvdata->width = 4;
+
+	addr_ctrl = readl(drvdata->base + SDRAM_ADDR_CTRL_REG);
+	rank_ctrl = readl(drvdata->base + SDRAM_RANK_CTRL_REG);
+	for (i = 0; i < SDRAM_NUM_CS; i++) {
+		dimm = mci->dimms[i];
+
+		if (!(rank_ctrl & SDRAM_RANK_CTRL_EXIST_MASK(i)))
+			continue;
+
+		drvdata->cs_addr_sel[i] =
+			!!(addr_ctrl & SDRAM_ADDR_CTRL_ADDR_SEL_MASK(i));
+
+		cs_struct = (addr_ctrl & SDRAM_ADDR_CTRL_STRUCT_MASK(i)) >> SDRAM_ADDR_CTRL_STRUCT_OFFSET(i);
+		cs_size   = ((addr_ctrl & SDRAM_ADDR_CTRL_SIZE_HIGH_MASK(i)) >> (SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(i) - 2) |
+			    ((addr_ctrl & SDRAM_ADDR_CTRL_SIZE_LOW_MASK(i)) >> SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(i)));
+
+		switch (cs_size) {
+		case 0: /* 2GBit */
+			dimm->nr_pages = 524288;
+			break;
+		case 1: /* 256MBit */
+			dimm->nr_pages = 65536;
+			break;
+		case 2: /* 512MBit */
+			dimm->nr_pages = 131072;
+			break;
+		case 3: /* 1GBit */
+			dimm->nr_pages = 262144;
+			break;
+		case 4: /* 4GBit */
+			dimm->nr_pages = 1048576;
+			break;
+		case 5: /* 8GBit */
+			dimm->nr_pages = 2097152;
+			break;
+		}
+		dimm->grain = 8;
+		dimm->dtype = cs_struct ? DEV_X16 : DEV_X8;
+		dimm->mtype = (config & SDRAM_CONFIG_REGISTERED_MASK) ?
+			MEM_RDDR3 : MEM_DDR3;
+		dimm->edac_mode = EDAC_SECDED;
+	}
+}
+
+static const struct of_device_id axp_mc_of_match[] = {
+	{.compatible = "marvell,armada-xp-sdram-controller",},
+	{},
+};
+MODULE_DEVICE_TABLE(of, axp_mc_of_match);
+
+static int axp_mc_probe(struct platform_device *pdev)
+{
+	struct axp_mc_drvdata *drvdata;
+	struct edac_mc_layer layers[1];
+	const struct of_device_id *id;
+	struct mem_ctl_info *mci;
+	struct resource *r;
+	void __iomem *base;
+	uint32_t config;
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "Unable to get mem resource\n");
+		return -ENODEV;
+	}
+
+	base = devm_ioremap_resource(&pdev->dev, r);
+	if (IS_ERR(base)) {
+		dev_err(&pdev->dev, "Unable to map regs\n");
+		return PTR_ERR(base);
+	}
+
+	config = readl(base + SDRAM_CONFIG_REG);
+	if (!(config & SDRAM_CONFIG_ECC_MASK)) {
+		dev_warn(&pdev->dev, "SDRAM ECC is not enabled");
+		return -EINVAL;
+	}
+
+	layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
+	layers[0].size = SDRAM_NUM_CS;
+	layers[0].is_virt_csrow = true;
+
+	mci = edac_mc_alloc(0, ARRAY_SIZE(layers), layers, sizeof(*drvdata));
+	if (!mci)
+		return -ENOMEM;
+
+	drvdata = mci->pvt_info;
+	drvdata->base = base;
+	mci->pdev = &pdev->dev;
+	platform_set_drvdata(pdev, mci);
+
+	id = of_match_device(axp_mc_of_match, &pdev->dev);
+	mci->edac_check = axp_mc_check;
+	mci->mtype_cap = MEM_FLAG_DDR3;
+	mci->edac_cap = EDAC_FLAG_SECDED;
+	mci->mod_name = pdev->dev.driver->name;
+	mci->ctl_name = id ? id->compatible : "unknown";
+	mci->dev_name = dev_name(&pdev->dev);
+	mci->scrub_mode = SCRUB_NONE;
+
+	axp_mc_read_config(mci);
+
+	/* configure SBE threshold */
+	/* it seems that SBEs are not captured otherwise */
+	writel(1 << SDRAM_ERR_CTRL_THR_OFFSET, drvdata->base + SDRAM_ERR_CTRL_REG);
+
+	/* clear cause registers */
+	writel(~(SDRAM_ERR_CAUSE_DBE_MASK | SDRAM_ERR_CAUSE_SBE_MASK), drvdata->base + SDRAM_ERR_CAUSE_ERR_REG);
+	writel(~(SDRAM_ERR_CAUSE_DBE_MASK | SDRAM_ERR_CAUSE_SBE_MASK), drvdata->base + SDRAM_ERR_CAUSE_MSG_REG);
+
+	/* clear counter registers */
+	writel(0, drvdata->base + SDRAM_ERR_SBE_COUNT_REG);
+	writel(0, drvdata->base + SDRAM_ERR_DBE_COUNT_REG);
+
+	if (edac_mc_add_mc(mci)) {
+		edac_mc_free(mci);
+		return -EINVAL;
+	}
+	edac_op_state = EDAC_OPSTATE_POLL;
+
+	return 0;
+}
+
+static int axp_mc_remove(struct platform_device *pdev)
+{
+	struct mem_ctl_info *mci = platform_get_drvdata(pdev);
+
+	edac_mc_del_mc(&pdev->dev);
+	edac_mc_free(mci);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver axp_mc_driver = {
+	.probe = axp_mc_probe,
+	.remove = axp_mc_remove,
+	.driver = {
+		.name = "armada_xp_mc_edac",
+		.of_match_table = of_match_ptr(axp_mc_of_match),
+	},
+};
+
+/************************ EDAC Device (L2 Cache) ***************************/
+
+struct aurora_l2_drvdata {
+	void __iomem *base;
+
+	char msg[128];
+
+	/* error injection via debugfs */
+	uint32_t inject_addr;
+	uint32_t inject_mask;
+	uint8_t inject_ctl;
+
+	struct dentry *debugfs;
+};
+
+#ifdef CONFIG_EDAC_DEBUG
+static void aurora_l2_inject(struct aurora_l2_drvdata *drvdata)
+{
+	drvdata->inject_addr &= AURORA_ERR_INJECT_CTL_ADDR_MASK;
+	drvdata->inject_ctl &= AURORA_ERR_INJECT_CTL_EN_MASK;
+	writel(0, drvdata->base + AURORA_ERR_INJECT_CTL_REG);
+	writel(drvdata->inject_mask, drvdata->base + AURORA_ERR_INJECT_MASK_REG);
+	writel(drvdata->inject_addr | drvdata->inject_ctl, drvdata->base + AURORA_ERR_INJECT_CTL_REG);
+}
+#endif
+
+static void aurora_l2_check(struct edac_device_ctl_info *dci)
+{
+	struct aurora_l2_drvdata *drvdata = dci->pvt_info;
+	uint32_t cnt, src, txn, err, attr_cap, addr_cap, way_cap;
+	unsigned int cnt_ce, cnt_ue;
+	char *msg = drvdata->msg;
+	size_t size = sizeof(drvdata->msg);
+	size_t len = 0;
+
+	cnt = readl(drvdata->base + AURORA_ERR_CNT_REG);
+	attr_cap = readl(drvdata->base + AURORA_ERR_ATTR_CAP_REG);
+	addr_cap = readl(drvdata->base + AURORA_ERR_ADDR_CAP_REG);
+	way_cap = readl(drvdata->base + AURORA_ERR_WAY_CAP_REG);
+
+	cnt_ce = (cnt & AURORA_ERR_CNT_CE_MASK) >> AURORA_ERR_CNT_CE_OFFSET;
+	cnt_ue = (cnt & AURORA_ERR_CNT_UE_MASK) >> AURORA_ERR_CNT_UE_OFFSET;
+	/* clear error counter registers */
+	if (cnt_ce || cnt_ue)
+		writel(AURORA_ERR_CNT_CLR, drvdata->base + AURORA_ERR_CNT_REG);
+
+	if (!(attr_cap & AURORA_ERR_ATTR_CAP_VALID))
+		goto clear_remaining;
+
+	src = (attr_cap & AURORA_ERR_ATTR_SRC_MSK) >> AURORA_ERR_ATTR_SRC_OFF;
+	if (src <= 3)
+		len += snprintf(msg+len, size-len, "src=CPU%d ", src);
+	else
+		len += snprintf(msg+len, size-len, "src=IO ");
+
+	txn =  (attr_cap & AURORA_ERR_ATTR_TXN_MSK) >> AURORA_ERR_ATTR_TXN_OFF;
+	switch (txn) {
+	case 0:
+		len += snprintf(msg+len, size-len, "txn=Data-Read ");
+		break;
+	case 1:
+		len += snprintf(msg+len, size-len, "txn=Isn-Read ");
+		break;
+	case 2:
+		len += snprintf(msg+len, size-len, "txn=Clean-Flush ");
+		break;
+	case 3:
+		len += snprintf(msg+len, size-len, "txn=Eviction ");
+		break;
+	case 4:
+		len += snprintf(msg+len, size-len,
+				"txn=Read-Modify-Write ");
+		break;
+	}
+
+	err = (attr_cap & AURORA_ERR_ATTR_ERR_MSK) >> AURORA_ERR_ATTR_ERR_OFF;
+	switch (err) {
+	case 0:
+		len += snprintf(msg+len, size-len, "err=CorrECC ");
+		break;
+	case 1:
+		len += snprintf(msg+len, size-len, "err=UnCorrECC ");
+		break;
+	case 2:
+		len += snprintf(msg+len, size-len, "err=TagParity ");
+		break;
+	}
+
+	len += snprintf(msg+len, size-len, "addr=0x%x ", addr_cap & AURORA_ERR_ADDR_CAP_ADDR_MASK);
+	len += snprintf(msg+len, size-len, "index=0x%x ", (way_cap & AURORA_ERR_WAY_IDX_MSK) >> AURORA_ERR_WAY_IDX_OFF);
+	len += snprintf(msg+len, size-len, "way=0x%x", (way_cap & AURORA_ERR_WAY_CAP_WAY_MASK) >> AURORA_ERR_WAY_CAP_WAY_OFFSET);
+
+	/* clear error capture registers */
+	writel(AURORA_ERR_ATTR_CAP_VALID, drvdata->base + AURORA_ERR_ATTR_CAP_REG);
+	if (err) {
+		/* UnCorrECC or TagParity */
+		if (cnt_ue)
+			cnt_ue--;
+		edac_device_handle_ue(dci, 0, 0, drvdata->msg);
+	} else {
+		if (cnt_ce)
+			cnt_ce--;
+		edac_device_handle_ce(dci, 0, 0, drvdata->msg);
+	}
+
+clear_remaining:
+	/* report remaining errors */
+	while (cnt_ue--)
+		edac_device_handle_ue(dci, 0, 0, "details unavailable (multiple errors)");
+	while (cnt_ce--)
+		edac_device_handle_ue(dci, 0, 0, "details unavailable (multiple errors)");
+}
+
+static void aurora_l2_poll(struct edac_device_ctl_info *dci)
+{
+#ifdef CONFIG_EDAC_DEBUG
+	struct aurora_l2_drvdata *drvdata = dci->pvt_info;
+#endif
+
+	aurora_l2_check(dci);
+#ifdef CONFIG_EDAC_DEBUG
+	aurora_l2_inject(drvdata);
+#endif
+}
+
+static const struct of_device_id aurora_l2_of_match[] = {
+	{.compatible = "marvell,aurora-system-cache",},
+	{},
+};
+MODULE_DEVICE_TABLE(of, aurora_l2_of_match);
+
+static int aurora_l2_probe(struct platform_device *pdev)
+{
+	struct aurora_l2_drvdata *drvdata;
+	struct edac_device_ctl_info *dci;
+	const struct of_device_id *id;
+	uint32_t l2x0_aux_ctrl;
+	void __iomem *base;
+	struct resource *r;
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		dev_err(&pdev->dev, "Unable to get mem resource\n");
+		return -ENODEV;
+	}
+
+	base = devm_ioremap_resource(&pdev->dev, r);
+	if (IS_ERR(base)) {
+		dev_err(&pdev->dev, "Unable to map regs\n");
+		return PTR_ERR(base);
+	}
+
+	l2x0_aux_ctrl = readl(base + L2X0_AUX_CTRL);
+	if (!(l2x0_aux_ctrl & AURORA_ACR_PARITY_EN))
+		dev_warn(&pdev->dev, "tag parity is not enabled");
+	if (!(l2x0_aux_ctrl & AURORA_ACR_ECC_EN))
+		dev_warn(&pdev->dev, "data ECC is not enabled");
+
+	dci = edac_device_alloc_ctl_info(sizeof(*drvdata),
+					 "cpu", 1, "L", 1, 2, NULL, 0, 0);
+	if (!dci)
+		return -ENOMEM;
+
+	drvdata = dci->pvt_info;
+	drvdata->base = base;
+	dci->dev = &pdev->dev;
+	platform_set_drvdata(pdev, dci);
+
+	id = of_match_device(aurora_l2_of_match, &pdev->dev);
+	dci->edac_check = aurora_l2_poll;
+	dci->mod_name = pdev->dev.driver->name;
+	dci->ctl_name = id ? id->compatible : "unknown";
+	dci->dev_name = dev_name(&pdev->dev);
+
+	/* clear registers */
+	writel(AURORA_ERR_CNT_CLR, drvdata->base + AURORA_ERR_CNT_REG);
+	writel(AURORA_ERR_ATTR_CAP_VALID, drvdata->base + AURORA_ERR_ATTR_CAP_REG);
+
+	if (edac_device_add_device(dci)) {
+		edac_device_free_ctl_info(dci);
+		return -EINVAL;
+	}
+
+#ifdef CONFIG_EDAC_DEBUG
+	drvdata->debugfs = edac_debugfs_create_dir(dev_name(&pdev->dev));
+	if (drvdata->debugfs) {
+		edac_debugfs_create_x32("inject_addr", 0644,
+					drvdata->debugfs,
+					&drvdata->inject_addr);
+		edac_debugfs_create_x32("inject_mask", 0644,
+					drvdata->debugfs,
+					&drvdata->inject_mask);
+		edac_debugfs_create_x8("inject_ctl", 0644,
+				       drvdata->debugfs, &drvdata->inject_ctl);
+	}
+#endif
+
+	return 0;
+}
+
+static int aurora_l2_remove(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *dci = platform_get_drvdata(pdev);
+#ifdef CONFIG_EDAC_DEBUG
+	struct aurora_l2_drvdata *drvdata = dci->pvt_info;
+
+	edac_debugfs_remove_recursive(drvdata->debugfs);
+#endif
+	edac_device_del_device(&pdev->dev);
+	edac_device_free_ctl_info(dci);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver aurora_l2_driver = {
+	.probe = aurora_l2_probe,
+	.remove = aurora_l2_remove,
+	.driver = {
+		.name = "aurora_l2_edac",
+		.of_match_table = of_match_ptr(aurora_l2_of_match),
+	},
+};
+
+/************************ Driver registration ******************************/
+
+static struct platform_driver * const drivers[] = {
+	&axp_mc_driver,
+	&aurora_l2_driver,
+};
+
+static int __init armada_xp_edac_init(void)
+{
+	int res;
+
+	/* only polling is supported */
+	edac_op_state = EDAC_OPSTATE_POLL;
+
+	res = platform_register_drivers(drivers, ARRAY_SIZE(drivers));
+	if (res)
+		pr_warn("Aramda XP EDAC drivers fail to register\n");
+
+	return 0;
+}
+module_init(armada_xp_edac_init);
+
+static void __exit armada_xp_edac_exit(void)
+{
+	platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
+}
+module_exit(armada_xp_edac_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Pengutronix");
+MODULE_DESCRIPTION("EDAC Drivers for Marvell Armada XP SDRAM and L2 Cache Controller");
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (6 preceding siblings ...)
  2019-07-12  3:49 ` [PATCH v9 7/8] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC Chris Packham
@ 2019-07-12  3:49 ` Chris Packham
  2019-07-26 14:51   ` James Morse
  2019-07-26 14:53 ` [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR James Morse
  8 siblings, 1 reply; 21+ messages in thread
From: Chris Packham @ 2019-07-12  3:49 UTC (permalink / raw)
  To: bp, robh+dt, mark.rutland, linux, patches, mchehab, james.morse, jlu
  Cc: devicetree, linux-arm-kernel, linux-edac, linux-kernel, Chris Packham

The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 drivers/edac/armada_xp_edac.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index 3759a4fbbdee..7f227bdcbc84 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -332,6 +332,11 @@ static int axp_mc_probe(struct platform_device *pdev)
 
 	axp_mc_read_config(mci);
 
+	/* These SoCs have a reduced width bus */
+	if (of_machine_is_compatible("marvell,armada380") ||
+	    of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+		drvdata->width /= 2;
+
 	/* configure SBE threshold */
 	/* it seems that SBEs are not captured otherwise */
 	writel(1 << SDRAM_ERR_CTRL_THR_OFFSET, drvdata->base + SDRAM_ERR_CTRL_REG);
-- 
2.22.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs
  2019-07-12  3:49 ` [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs Chris Packham
@ 2019-07-26 14:51   ` James Morse
  2019-07-28 20:52     ` Chris Packham
  0 siblings, 1 reply; 21+ messages in thread
From: James Morse @ 2019-07-26 14:51 UTC (permalink / raw)
  To: Chris Packham
  Cc: bp, robh+dt, mark.rutland, linux, patches, mchehab, jlu,
	devicetree, linux-arm-kernel, linux-edac, linux-kernel

Hi Chris,

On 12/07/2019 04:49, Chris Packham wrote:
> The Armada 38x and other integrated SoCs use a reduced pin count so the
> width of the SDRAM interface is smaller than the Armada XP SoCs. This
> means that the definition of "full" and "half" width is reduced from
> 64/32 to 32/16.

> diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
> index 3759a4fbbdee..7f227bdcbc84 100644
> --- a/drivers/edac/armada_xp_edac.c
> +++ b/drivers/edac/armada_xp_edac.c
> @@ -332,6 +332,11 @@ static int axp_mc_probe(struct platform_device *pdev)
>  
>  	axp_mc_read_config(mci);
>  
> +	/* These SoCs have a reduced width bus */
> +	if (of_machine_is_compatible("marvell,armada380") ||
> +	    of_machine_is_compatible("marvell,armadaxp-98dx3236"))
> +		drvdata->width /= 2;

So the hardware's SDRAM_CONFIG_BUS_WIDTH value is wrong? Yuck.

Is it too late for the DTs on these two systems to provide a DT version of the 'bus_width'
to override the hardware's mis-advertised value?

This way you don't need to grow this list.

Acked-by: James Morse <james.morse@arm.com>


Thanks,

James

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR
  2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
                   ` (7 preceding siblings ...)
  2019-07-12  3:49 ` [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs Chris Packham
@ 2019-07-26 14:53 ` James Morse
  2019-07-28 20:33   ` Chris Packham
  8 siblings, 1 reply; 21+ messages in thread
From: James Morse @ 2019-07-26 14:53 UTC (permalink / raw)
  To: Chris Packham
  Cc: bp, robh+dt, mark.rutland, linux, patches, mchehab, jlu,
	devicetree, linux-arm-kernel, linux-edac, linux-kernel

Hi Chris,

On 12/07/2019 04:48, Chris Packham wrote:
> I still seem to be struggling to get this on anyone's radar.

Whose radar does it need to cross?


> The Reviews/Acks have been given so this should be good to go in via the ARM
> tree as planned.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

For your v8 I took this to mean this series was done!

If nothing has changed with Boris and Russell's decision (it was two years ago....),
details of the patch system are here:

https://lore.kernel.org/linux-arm-kernel/20190624142346.pxljv3m4npatdiyk@shell.armlinux.org.uk/


Thanks,

James

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR
  2019-07-26 14:53 ` [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR James Morse
@ 2019-07-28 20:33   ` Chris Packham
  0 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-28 20:33 UTC (permalink / raw)
  To: james.morse
  Cc: linux-kernel, robh+dt, linux, devicetree, mchehab, mark.rutland,
	jlu, bp, linux-arm-kernel, patches, linux-edac

On Fri, 2019-07-26 at 15:53 +0100, James Morse wrote:
> Hi Chris,
> 
> On 12/07/2019 04:48, Chris Packham wrote:
> > 
> > I still seem to be struggling to get this on anyone's radar.
> Whose radar does it need to cross?
> 

That's a good question. The last solid guidance I had was that this
series was going in via the ARM tree. But as you say below that was two
years ago.

I only realised recently that the ARM core seems to have a different
workflow to other kernel subsystems.

> 
> > 
> > The Reviews/Acks have been given so this should be good to go in
> > via the ARM
> > tree as planned.
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/5
> > 25561.html
> For your v8 I took this to mean this series was done!
> 
> If nothing has changed with Boris and Russell's decision (it was two
> years ago....),
> details of the patch system are here:
> 
> https://lore.kernel.org/linux-arm-kernel/20190624142346.pxljv3m4npatd
> iyk@shell.armlinux.org.uk/
> 

Thanks for the link. I would have never found that. I did try to follow
what I could find on https://www.armlinux.org.uk/developer/ but a lot
of that seems to be out of date.

I did manage to submit v9  to the ARM patch tracker but naturally I
messed it up the first time https://www.armlinux.org.uk/developer/patch
es/viewpatch.php?id=8877/1 and I'm not sure I got the second attempt
right either https://www.armlinux.org.uk/developer/patches/viewpatch.ph
p?id=8885/1


> Thanks,
> 
> James

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs
  2019-07-26 14:51   ` James Morse
@ 2019-07-28 20:52     ` Chris Packham
  0 siblings, 0 replies; 21+ messages in thread
From: Chris Packham @ 2019-07-28 20:52 UTC (permalink / raw)
  To: james.morse
  Cc: linux-kernel, robh+dt, linux, devicetree, mchehab, mark.rutland,
	jlu, bp, linux-arm-kernel, patches, linux-edac

On Fri, 2019-07-26 at 15:51 +0100, James Morse wrote:
> Hi Chris,
> 
> On 12/07/2019 04:49, Chris Packham wrote:
> > 
> > The Armada 38x and other integrated SoCs use a reduced pin count so
> > the
> > width of the SDRAM interface is smaller than the Armada XP SoCs.
> > This
> > means that the definition of "full" and "half" width is reduced
> > from
> > 64/32 to 32/16.
> > 
> > diff --git a/drivers/edac/armada_xp_edac.c
> > b/drivers/edac/armada_xp_edac.c
> > index 3759a4fbbdee..7f227bdcbc84 100644
> > --- a/drivers/edac/armada_xp_edac.c
> > +++ b/drivers/edac/armada_xp_edac.c
> > @@ -332,6 +332,11 @@ static int axp_mc_probe(struct platform_device
> > *pdev)
> >  
> >  	axp_mc_read_config(mci);
> >  
> > +	/* These SoCs have a reduced width bus */
> > +	if (of_machine_is_compatible("marvell,armada380") ||
> > +	    of_machine_is_compatible("marvell,armadaxp-98dx3236"))
> > +		drvdata->width /= 2;
> So the hardware's SDRAM_CONFIG_BUS_WIDTH value is wrong? Yuck.
> 

The maximum width differs between Armada-XP (64-bit) and Armada-38x
(32-bit). There is still strapping to control half-width vs full-width.

> Is it too late for the DTs on these two systems to provide a DT
> version of the 'bus_width'
> to override the hardware's mis-advertised value?

In an earlier iteration I did have a DT property as you suggest. The
problem is that something like "bus-width = <32>" is ambiguous. On
Armada-XP this means the strapping is for half-width but on Armada-38x
you'd need to strap to full-width. That's why we settled on the mode
interpreting the strapping against SoC[1].

[1] https://lore.kernel.org/linux-arm-kernel/1502444067.1333.7.camel@pe
ngutronix.de/

> 
> This way you don't need to grow this list.
> 
> Acked-by: James Morse <james.morse@arm.com>
> 
> 
> Thanks,
> 
> James

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-07-12  3:48 ` [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE Chris Packham
@ 2019-08-23 10:46   ` Russell King - ARM Linux admin
  2019-08-23 10:50     ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 21+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-23 10:46 UTC (permalink / raw)
  To: Chris Packham
  Cc: bp, robh+dt, mark.rutland, patches, mchehab, james.morse, jlu,
	devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Gregory CLEMENT

On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> From: Jan Luebbe <jlu@pengutronix.de>
> 
> The macro name is too generic, so add a AURORA_ prefix.
> 
> Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-

I can't apply this series - this file does not exist in my tree, and
from what git tells me, it never has existed.  Maybe it's in someone
elses tree?

>  arch/arm/mm/cache-l2x0.c                        | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> index c86124769831..dc5c479ec4c3 100644
> --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> @@ -41,7 +41,7 @@
>  #define AURORA_ACR_FORCE_WRITE_THRO_POLICY	\
>  	(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
>  
> -#define MAX_RANGE_SIZE		1024
> +#define AURORA_MAX_RANGE_SIZE	1024
>  
>  #define AURORA_WAY_SIZE_SHIFT	2
>  
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 428d08718107..83b733a1f1e6 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
>  	 * since cache range operations stall the CPU pipeline
>  	 * until completion.
>  	 */
> -	if (end > start + MAX_RANGE_SIZE)
> -		end = start + MAX_RANGE_SIZE;
> +	if (end > start + AURORA_MAX_RANGE_SIZE)
> +		end = start + AURORA_MAX_RANGE_SIZE;
>  
>  	/*
>  	 * Cache range operations can't straddle a page boundary.
> -- 
> 2.22.0
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-23 10:46   ` Russell King - ARM Linux admin
@ 2019-08-23 10:50     ` Russell King - ARM Linux admin
  2019-08-26  0:46       ` Chris Packham
  0 siblings, 1 reply; 21+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-23 10:50 UTC (permalink / raw)
  To: Chris Packham
  Cc: bp, robh+dt, mark.rutland, patches, mchehab, james.morse, jlu,
	devicetree, linux-arm-kernel, linux-edac, linux-kernel,
	Gregory CLEMENT

On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > From: Jan Luebbe <jlu@pengutronix.de>
> > 
> > The macro name is too generic, so add a AURORA_ prefix.
> > 
> > Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > ---
> >  arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
> 
> I can't apply this series - this file does not exist in my tree, and
> from what git tells me, it never has existed.  Maybe it's in someone
> elses tree?

I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
which is where it has been since it was originally submitted in 2012.

> 
> >  arch/arm/mm/cache-l2x0.c                        | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > index c86124769831..dc5c479ec4c3 100644
> > --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > @@ -41,7 +41,7 @@
> >  #define AURORA_ACR_FORCE_WRITE_THRO_POLICY	\
> >  	(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
> >  
> > -#define MAX_RANGE_SIZE		1024
> > +#define AURORA_MAX_RANGE_SIZE	1024
> >  
> >  #define AURORA_WAY_SIZE_SHIFT	2
> >  
> > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > index 428d08718107..83b733a1f1e6 100644
> > --- a/arch/arm/mm/cache-l2x0.c
> > +++ b/arch/arm/mm/cache-l2x0.c
> > @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> >  	 * since cache range operations stall the CPU pipeline
> >  	 * until completion.
> >  	 */
> > -	if (end > start + MAX_RANGE_SIZE)
> > -		end = start + MAX_RANGE_SIZE;
> > +	if (end > start + AURORA_MAX_RANGE_SIZE)
> > +		end = start + AURORA_MAX_RANGE_SIZE;
> >  
> >  	/*
> >  	 * Cache range operations can't straddle a page boundary.
> > -- 
> > 2.22.0
> > 
> > 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-23 10:50     ` Russell King - ARM Linux admin
@ 2019-08-26  0:46       ` Chris Packham
  2019-08-27  9:13         ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 21+ messages in thread
From: Chris Packham @ 2019-08-26  0:46 UTC (permalink / raw)
  To: linux
  Cc: linux-kernel, robh+dt, devicetree, james.morse, mchehab,
	mark.rutland, gregory.clement, jlu, bp, linux-arm-kernel,
	patches, linux-edac

Hi Russell,

On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
wrote:
> On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> admin wrote:
> > On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > > From: Jan Luebbe <jlu@pengutronix.de>
> > > 
> > > The macro name is too generic, so add a AURORA_ prefix.
> > > 
> > > Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> > > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > > ---
> > >  arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
> > 
> > I can't apply this series - this file does not exist in my tree,
> > and
> > from what git tells me, it never has existed.  Maybe it's in
> > someone
> > elses tree?
> 
> I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> which is where it has been since it was originally submitted in 2012.
> 

Sorry there is a missing patch that moves it next to the
hardware/cache-*.h. I can send the missing patch or I can re-send the
whole series. If I do send the whole series do you want me to rebase it
against a particular tag/tree?

> > 
> > >  arch/arm/mm/cache-l2x0.c                        | 4 ++--
> > >  2 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > index c86124769831..dc5c479ec4c3 100644
> > > --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > @@ -41,7 +41,7 @@
> > >  #define AURORA_ACR_FORCE_WRITE_THRO_POLICY	\
> > >  	(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
> > >  
> > > -#define MAX_RANGE_SIZE		1024
> > > +#define AURORA_MAX_RANGE_SIZE	1024
> > >  
> > >  #define AURORA_WAY_SIZE_SHIFT	2
> > >  
> > > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > > index 428d08718107..83b733a1f1e6 100644
> > > --- a/arch/arm/mm/cache-l2x0.c
> > > +++ b/arch/arm/mm/cache-l2x0.c
> > > @@ -1352,8 +1352,8 @@ static unsigned long
> > > aurora_range_end(unsigned long start, unsigned long end)
> > >  	 * since cache range operations stall the CPU pipeline
> > >  	 * until completion.
> > >  	 */
> > > -	if (end > start + MAX_RANGE_SIZE)
> > > -		end = start + MAX_RANGE_SIZE;
> > > +	if (end > start + AURORA_MAX_RANGE_SIZE)
> > > +		end = start + AURORA_MAX_RANGE_SIZE;
> > >  
> > >  	/*
> > >  	 * Cache range operations can't straddle a page boundary.
> > > -- 
> > > 2.22.0
> > > 
> > > 
> > 
> > -- 
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down
> > 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
> 
> 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-26  0:46       ` Chris Packham
@ 2019-08-27  9:13         ` Russell King - ARM Linux admin
  2019-08-27 20:56           ` Chris Packham
  0 siblings, 1 reply; 21+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-27  9:13 UTC (permalink / raw)
  To: Chris Packham
  Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
	james.morse, gregory.clement, bp, mchehab, linux-arm-kernel,
	patches

On Mon, Aug 26, 2019 at 12:46:44AM +0000, Chris Packham wrote:
> Hi Russell,
> 
> On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> > admin wrote:
> > > I can't apply this series - this file does not exist in my tree,
> > > and
> > > from what git tells me, it never has existed.  Maybe it's in
> > > someone
> > > elses tree?
> > 
> > I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> > which is where it has been since it was originally submitted in 2012.
> 
> Sorry there is a missing patch that moves it next to the
> hardware/cache-*.h. I can send the missing patch or I can re-send the
> whole series. If I do send the whole series do you want me to rebase it
> against a particular tag/tree?

Just send the single patch to the patch tracker - having it against
5.3-rc is fine (I don't think anything has changed for a long time
with that file.)

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-27  9:13         ` Russell King - ARM Linux admin
@ 2019-08-27 20:56           ` Chris Packham
  2019-08-27 21:07             ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 21+ messages in thread
From: Chris Packham @ 2019-08-27 20:56 UTC (permalink / raw)
  To: linux
  Cc: linux-kernel, robh+dt, devicetree, james.morse, mchehab,
	mark.rutland, gregory.clement, jlu, bp, linux-arm-kernel,
	linux-edac, patches

On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
wrote:
> On Mon, Aug 26, 2019 at 12:46:44AM +0000, Chris Packham wrote:
> > Hi Russell,
> > 
> > On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> > > admin wrote:
> > > > I can't apply this series - this file does not exist in my tree,
> > > > and
> > > > from what git tells me, it never has existed.  Maybe it's in
> > > > someone
> > > > elses tree?
> > > 
> > > I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> > > which is where it has been since it was originally submitted in 2012.
> > 
> > Sorry there is a missing patch that moves it next to the
> > hardware/cache-*.h. I can send the missing patch or I can re-send the
> > whole series. If I do send the whole series do you want me to rebase it
> > against a particular tag/tree?
> 
> Just send the single patch to the patch tracker - having it against
> 5.3-rc is fine (I don't think anything has changed for a long time
> with that file.)

Done 
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1

I'm still not entirely sure what to put for the KernelVersion tag. In
hindsight think I misinterpreted your comment above and set it to 5.3rc
(where you meant a series based on 5.3-rcX should apply cleanly). It
probably should have been next or master because it's way past the
merge window for 5.3.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-27 20:56           ` Chris Packham
@ 2019-08-27 21:07             ` Russell King - ARM Linux admin
  2019-08-27 21:13               ` Chris Packham
  0 siblings, 1 reply; 21+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-27 21:07 UTC (permalink / raw)
  To: Chris Packham
  Cc: linux-kernel, robh+dt, devicetree, james.morse, mchehab,
	mark.rutland, gregory.clement, jlu, bp, linux-arm-kernel,
	linux-edac, patches

On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> wrote:
> > Just send the single patch to the patch tracker - having it against
> > 5.3-rc is fine (I don't think anything has changed for a long time
> > with that file.)
> 
> Done 
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> 
> I'm still not entirely sure what to put for the KernelVersion tag. In
> hindsight think I misinterpreted your comment above and set it to 5.3rc
> (where you meant a series based on 5.3-rcX should apply cleanly). It
> probably should have been next or master because it's way past the
> merge window for 5.3.

Think about it as "which kernel version was _this_ patch generated
against" - it's a guide for me to know which kernel version it
should be applied to.  The nearest Linus release (rc or final) is
generally sufficient.

If it doesn't apply to my current base, then I might check out that
version, apply it there, and then merge it in, resolving any
conflicts during the merge.

It started off with a different purpose: when we had the older
development system, such as the 2.x series kernels, we would have
even x being the current stable kernels, and concurrently we'd
also have x+1 as the development series.  When someone sent me a
patch back then, it was important to know which kernel series it
was meant for.

I decided not to get rid of it because it provides useful
information when patches don't apply, and gives more options
than me just discarding the patch with a comment saying it
doesn't apply.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-27 21:07             ` Russell King - ARM Linux admin
@ 2019-08-27 21:13               ` Chris Packham
  2019-08-27 21:15                 ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 21+ messages in thread
From: Chris Packham @ 2019-08-27 21:13 UTC (permalink / raw)
  To: linux
  Cc: linux-kernel, robh+dt, devicetree, james.morse, mchehab,
	gregory.clement, mark.rutland, jlu, bp, linux-arm-kernel,
	linux-edac, patches

On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
wrote:
> On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > wrote:
> > > Just send the single patch to the patch tracker - having it against
> > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > with that file.)
> > 
> > Done 
> > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> > 
> > I'm still not entirely sure what to put for the KernelVersion tag. In
> > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > probably should have been next or master because it's way past the
> > merge window for 5.3.
> 
> Think about it as "which kernel version was _this_ patch generated
> against" - it's a guide for me to know which kernel version it
> should be applied to.  The nearest Linus release (rc or final) is
> generally sufficient.
> 
> If it doesn't apply to my current base, then I might check out that
> version, apply it there, and then merge it in, resolving any
> conflicts during the merge.
> 
> It started off with a different purpose: when we had the older
> development system, such as the 2.x series kernels, we would have
> even x being the current stable kernels, and concurrently we'd
> also have x+1 as the development series.  When someone sent me a
> patch back then, it was important to know which kernel series it
> was meant for.
> 
> I decided not to get rid of it because it provides useful
> information when patches don't apply, and gives more options
> than me just discarding the patch with a comment saying it
> doesn't apply.
> 

Thanks for the info. So 5.3-rc is not as wrong as I thought it was.

One could even summarize the above as.

  git format-patch --add-header \
      "KernelVersion: $(git describe --abbrev=0 HEAD)"


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  2019-08-27 21:13               ` Chris Packham
@ 2019-08-27 21:15                 ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 21+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-27 21:15 UTC (permalink / raw)
  To: Chris Packham
  Cc: linux-kernel, robh+dt, devicetree, james.morse, mchehab,
	gregory.clement, mark.rutland, jlu, bp, linux-arm-kernel,
	linux-edac, patches

On Tue, Aug 27, 2019 at 09:13:11PM +0000, Chris Packham wrote:
> On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > > wrote:
> > > > Just send the single patch to the patch tracker - having it against
> > > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > > with that file.)
> > > 
> > > Done 
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> > > 
> > > I'm still not entirely sure what to put for the KernelVersion tag. In
> > > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > > probably should have been next or master because it's way past the
> > > merge window for 5.3.
> > 
> > Think about it as "which kernel version was _this_ patch generated
> > against" - it's a guide for me to know which kernel version it
> > should be applied to.  The nearest Linus release (rc or final) is
> > generally sufficient.
> > 
> > If it doesn't apply to my current base, then I might check out that
> > version, apply it there, and then merge it in, resolving any
> > conflicts during the merge.
> > 
> > It started off with a different purpose: when we had the older
> > development system, such as the 2.x series kernels, we would have
> > even x being the current stable kernels, and concurrently we'd
> > also have x+1 as the development series.  When someone sent me a
> > patch back then, it was important to know which kernel series it
> > was meant for.
> > 
> > I decided not to get rid of it because it provides useful
> > information when patches don't apply, and gives more options
> > than me just discarding the patch with a comment saying it
> > doesn't apply.
> > 
> 
> Thanks for the info. So 5.3-rc is not as wrong as I thought it was.
> 
> One could even summarize the above as.
> 
>   git format-patch --add-header \
>       "KernelVersion: $(git describe --abbrev=0 HEAD)"

Yep, I should probably update the patch system help with that, and
actually strip out everything about the old diff and patch way of
working.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-12  3:48 [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR Chris Packham
2019-07-12  3:48 ` [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE Chris Packham
2019-08-23 10:46   ` Russell King - ARM Linux admin
2019-08-23 10:50     ` Russell King - ARM Linux admin
2019-08-26  0:46       ` Chris Packham
2019-08-27  9:13         ` Russell King - ARM Linux admin
2019-08-27 20:56           ` Chris Packham
2019-08-27 21:07             ` Russell King - ARM Linux admin
2019-08-27 21:13               ` Chris Packham
2019-08-27 21:15                 ` Russell King - ARM Linux admin
2019-07-12  3:48 ` [PATCH v9 2/8] ARM: aurora-l2: add defines for parity and ECC registers Chris Packham
2019-07-12  3:48 ` [PATCH v9 3/8] ARM: l2x0: support parity-enable/disable on aurora Chris Packham
2019-07-12  3:49 ` [PATCH v9 4/8] dt-bindings: ARM: document marvell,ecc-enable binding Chris Packham
2019-07-12  3:49 ` [PATCH v9 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora Chris Packham
2019-07-12  3:49 ` [PATCH v9 6/8] EDAC: Add missing debugfs_create_x32 wrapper Chris Packham
2019-07-12  3:49 ` [PATCH v9 7/8] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC Chris Packham
2019-07-12  3:49 ` [PATCH v9 8/8] EDAC: armada_xp: Add support for more SoCs Chris Packham
2019-07-26 14:51   ` James Morse
2019-07-28 20:52     ` Chris Packham
2019-07-26 14:53 ` [PATCH v9 0/8] EDAC drivers for Armada XP L2 and DDR James Morse
2019-07-28 20:33   ` Chris Packham

Linux-EDAC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-edac/0 linux-edac/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-edac linux-edac/ https://lore.kernel.org/linux-edac \
		linux-edac@vger.kernel.org linux-edac@archiver.kernel.org
	public-inbox-index linux-edac


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-edac


AGPL code for this site: git clone https://public-inbox.org/ public-inbox