Skip to contentSkip to conversation

ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x

PATCH New Gregory CLEMENT 3 participants 4 messages Jun 26, 2014

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x

From: Nadav Haklai <[email protected]>

When set, coherent linefill requests are sent speculatively to the L2C-310 in parallel with the tag look-up. If the tag look-up misses, the confirmed linefill is sent to the L2C-310 and gets RDATA earlier because the data request was already initiated by the speculative request.

This feature may improve overall system performance.

[Gregory: use a define for the SCU Speculative linefills enable bit, modify the title of the patch]

---
 arch/arm/mach-mvebu/board-v7.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)
arch/arm/mach-mvebu/board-v7.c +12 -0
index 8bb742fdf5ca..c9b02651e895 100644
@@ -33,6 +33,10 @@
 #include "coherency.h"
 #include "mvebu-soc-id.h"
 
+#define SCU_CTRL		0x00
+#define SCU_SPEC_LINEFILL_EN	    BIT(3)
+
+
 /*
  * Enables the SCU when available. Obviously, this is only useful on
  * Cortex-A based SOCs, not on PJ4B based ones.
@@ -44,7 +48,15 @@ static void __init mvebu_scu_enable(void)
 	struct device_node *np =
 		of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
 	if (np) {
+		u32 scu_ctrl;
 		scu_base = of_iomap(np, 0);
+		/* already enabled? */
+		scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+		if (!(scu_ctrl & 1)) {
+			/* Enable SCU Speculative linefills to L2 */
+			scu_ctrl |= SCU_SPEC_LINEFILL_EN;
+			__raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+		}
 		scu_enable(scu_base);
 		of_node_put(np);
 	}
Signature · 1 line
1.8.1.2
#1 lore raw

PATCH 1/1 ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x

Dear Gregory CLEMENT,

Quoted 8 lines · Gregory CLEMENT
arch/arm/mach-mvebu/board-v7.c +4 -0
+#define SCU_CTRL		0x00
+#define SCU_SPEC_LINEFILL_EN	    BIT(3)
+
+
 /*
  * Enables the SCU when available. Obviously, this is only useful on
  * Cortex-A based SOCs, not on PJ4B based ones.

arch/arm/mach-mvebu/board-v7.c static void __init mvebu_scu_enable(void) · line 54

Quoted 7 lines
arch/arm/mach-mvebu/board-v7.c +3 -0
@@ -44,7 +48,15 @@ static void __init mvebu_scu_enable(void)
 	struct device_node *np =
 		of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
 	if (np) {
+		u32 scu_ctrl;
 		scu_base = of_iomap(np, 0);
+		/* already enabled? */
+		scu_ctrl = __raw_readl(scu_base + SCU_CTRL);

Unless the SCU uses the native endianess of the system, and therefore switches to big endian when the system is running big endian, using __raw_{readl,writel} is wrong here, and will break big endian configurations.

arch/arm/mach-mvebu/board-v7.c static void __init mvebu_scu_enable(void) · line 55

Quoted 1 line
arch/arm/mach-mvebu/board-v7.c +1 -0
+		if (!(scu_ctrl & 1)) {

What is this bit 0 you're checking here? How does it relate to the bit 3 you're setting when bit 0 is not set?

A broader question is: if this feature is generic to all Cortex-A9, why not offer a function in smp_scu.c to enable it? It seems weird to have the offset and bit definitions for something as generic as the SCU present deep into a Marvell-specific file.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#2 lore raw

PATCH 1/1 ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x

Hi Thomas,

Quoted 16 lines · Thomas Petazzoni

Dear Gregory CLEMENT,

Quoted 12 lines · Gregory CLEMENT
arch/arm/mach-mvebu/board-v7.c +5 -0
+#define SCU_CTRL		0x00
+#define SCU_SPEC_LINEFILL_EN	    BIT(3)
+
+
 /*
  * Enables the SCU when available. Obviously, this is only useful on
  * Cortex-A based SOCs, not on PJ4B based ones.
@@ -44,7 +48,15 @@ static void __init mvebu_scu_enable(void)
 	struct device_node *np =
 		of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
 	if (np) {
+		u32 scu_ctrl;
Quoted 8 lines

arch/arm/mach-mvebu/board-v7.c static void __init mvebu_scu_enable(void) · line 54

Quoted 3 lines
arch/arm/mach-mvebu/board-v7.c +2 -0
 		scu_base = of_iomap(np, 0);
+		/* already enabled? */
+		scu_ctrl = __raw_readl(scu_base + SCU_CTRL);

Unless the SCU uses the native endianess of the system, and therefore switches to big endian when the system is running big endian, using __raw_{readl,writel} is wrong here, and will break big endian configurations.

Yes you are right here.

Quoted 5 lines

arch/arm/mach-mvebu/board-v7.c static void __init mvebu_scu_enable(void) · line 55

Quoted 2 lines
arch/arm/mach-mvebu/board-v7.c +1 -0
+		if (!(scu_ctrl & 1)) {

What is this bit 0 you're checking here? How does it relate to the bit 3 you're setting when bit 0 is not set?

It is related to the comment just before: we checked if the SCU is already enabled. So I guess we can't set the SCU Speculative linefills bit if the SCU is enabled.

Quoted 5 lines

A broader question is: if this feature is generic to all Cortex-A9, why not offer a function in smp_scu.c to enable it? It seems weird to have the offset and bit definitions for something as generic as the SCU present deep into a Marvell-specific file.

I have no strong opinion on it, and I also thoough about adding a function in smp_scu.c but when you are looking at the usage of SCU is the kernel the other SOC manipulate it directly.

Thanks,

Gregory

Signature · 4 lines
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
maintainer
#3 lore raw

PATCH 1/1 ARM: mvebu: Enable SCU Speculative linefills to L2 for Armada 375/38x

Quoted 8 lines
Quoted 4 lines

A broader question is: if this feature is generic to all Cortex-A9, why not offer a function in smp_scu.c to enable it? It seems weird to have the offset and bit definitions for something as generic as the SCU present deep into a Marvell-specific file.

I have no strong opinion on it, and I also thoough about adding a function in smp_scu.c but when you are looking at the usage of SCU is the kernel the other SOC manipulate it directly.

Hi Gregory

Is that just cult cargo coding? Maybe now is the time to refactor this into one central location?

Andrew