[PATCH V2 0/5] SMP support for Armada XP

[PATCH V2 0/5] SMP support for Armada XP

[Gregory CLEMENT]

Hello,

The purpose of this patch set is to add the SMP support for the Armada
XP SoCs. Beside the SMP support itself brought by the last 3 patches,
this patch set also adds the support for the coherency fabric unit and
the power management service unit.

The coherency fabric is responsible for ensuring hardware coherency
between all CPUs and between CPUs and I/O masters. This unit is also
available for Armada 370 and will be used in an incoming patch set
for hardware I/O cache coherency.

The power management service unit is responsible for powering down and
waking up CPUs and other SOC units.

The original code is from Yehuda Yitschak, it was reworked by myself
and reviewed by Yehuda.

This patch set is based on 3.7-rc3 and depends one the framework clock
support (the last version was posted 2 weeks ago:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called ArmadaXP-SMP-for-3.8-V2 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.

Arnd, Olof, as this code is SoC specific will you be able to pull it
through Jason tree? Or should I push the part added in
arch/arm/mm/proc-v7.S to support PJ4B CPU through Russell tree?

Changelog:
V1 -> V2:
- Rebased on to v3.7-rc3
- Fixed typos found by Alexandre Belloni
- Added clk_prepare_enable() before getting rate clk in
  set_secondary_cpus_clock()
- Add explanation in the binding documentation about the per-CPU
  interrupt registers: the address of the virtual register must be
  used.
- Removed the armada_xp prefix in the coherency.c file to be more
  compliant with the name convention of the other files.
- Coherency_init is now called from armada_370_xp_dt_init() and is no
  more an early_init() call. As the device tree is not available from
  an early_init(), it was useless to call coherency_init() so
  early. The need to be able to call some function very early during
  the boot were already resolved by using the hard code address of the
  register.

Regards,

Yehuda Yitschak (5):
  arm: mvebu: Added support for coherency fabric in mach-mvebu
  arm: mvebu: Added initial support for power managmement service unit
  arm: mvebu: Added IPI support via doorbells
  arm: mm: Added support for PJ4B cpu and init routines
  arm: mvebu: Added SMP support for Armada XP

 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 +-
 .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 ++++
 .../devicetree/bindings/arm/coherency-fabric.txt   |   16 +++
 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 +
 arch/arm/boot/dts/armada-xp.dtsi                   |   12 +-
 arch/arm/configs/mvebu_defconfig                   |    3 +
 arch/arm/mach-mvebu/Kconfig                        |    3 +-
 arch/arm/mach-mvebu/Makefile                       |    4 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |    3 +
 arch/arm/mach-mvebu/armada-370-xp.h                |   10 ++
 arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++
 arch/arm/mach-mvebu/coherency.h                    |   21 ++++
 arch/arm/mach-mvebu/common.h                       |    6 +
 arch/arm/mach-mvebu/headsmp.S                      |   66 +++++++++++
 arch/arm/mach-mvebu/hotplug.c                      |   30 +++++
 arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++-
 arch/arm/mach-mvebu/platsmp.c                      |  124 ++++++++++++++++++++
 arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++
 arch/arm/mach-mvebu/pmsu.h                         |   16 +++
 arch/arm/mm/Kconfig                                |    4 +
 arch/arm/mm/proc-v7.S                              |   46 ++++++++
 21 files changed, 648 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
 create mode 100644 arch/arm/mach-mvebu/coherency.c
 create mode 100644 arch/arm/mach-mvebu/coherency.h
 create mode 100644 arch/arm/mach-mvebu/headsmp.S
 create mode 100644 arch/arm/mach-mvebu/hotplug.c
 create mode 100644 arch/arm/mach-mvebu/platsmp.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.h

-- 
1.7.9.5

[PATCH V2 0/5] SMP support for Armada XP

[Gregory CLEMENT]

Hello,

The purpose of this patch set is to add the SMP support for the Armada
XP SoCs. Beside the SMP support itself brought by the last 3 patches,
this patch set also adds the support for the coherency fabric unit and
the power management service unit.

The coherency fabric is responsible for ensuring hardware coherency
between all CPUs and between CPUs and I/O masters. This unit is also
available for Armada 370 and will be used in an incoming patch set
for hardware I/O cache coherency.

The power management service unit is responsible for powering down and
waking up CPUs and other SOC units.

The original code is from Yehuda Yitschak, it was reworked by myself
and reviewed by Yehuda.

This patch set is based on 3.7-rc3 and depends one the framework clock
support (the last version was posted 2 weeks ago:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called ArmadaXP-SMP-for-3.8-V2 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.

Arnd, Olof, as this code is SoC specific will you be able to pull it
through Jason tree? Or should I push the part added in
arch/arm/mm/proc-v7.S to support PJ4B CPU through Russell tree?

Changelog:
V1 -> V2:
- Rebased on to v3.7-rc3
- Fixed typos found by Alexandre Belloni
- Added clk_prepare_enable() before getting rate clk in
  set_secondary_cpus_clock()
- Add explanation in the binding documentation about the per-CPU
  interrupt registers: the address of the virtual register must be
  used.
- Removed the armada_xp prefix in the coherency.c file to be more
  compliant with the name convention of the other files.
- Coherency_init is now called from armada_370_xp_dt_init() and is no
  more an early_init() call. As the device tree is not available from
  an early_init(), it was useless to call coherency_init() so
  early. The need to be able to call some function very early during
  the boot were already resolved by using the hard code address of the
  register.

Regards,

Yehuda Yitschak (5):
  arm: mvebu: Added support for coherency fabric in mach-mvebu
  arm: mvebu: Added initial support for power managmement service unit
  arm: mvebu: Added IPI support via doorbells
  arm: mm: Added support for PJ4B cpu and init routines
  arm: mvebu: Added SMP support for Armada XP

 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 +-
 .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 ++++
 .../devicetree/bindings/arm/coherency-fabric.txt   |   16 +++
 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 +
 arch/arm/boot/dts/armada-xp.dtsi                   |   12 +-
 arch/arm/configs/mvebu_defconfig                   |    3 +
 arch/arm/mach-mvebu/Kconfig                        |    3 +-
 arch/arm/mach-mvebu/Makefile                       |    4 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |    3 +
 arch/arm/mach-mvebu/armada-370-xp.h                |   10 ++
 arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++
 arch/arm/mach-mvebu/coherency.h                    |   21 ++++
 arch/arm/mach-mvebu/common.h                       |    6 +
 arch/arm/mach-mvebu/headsmp.S                      |   66 +++++++++++
 arch/arm/mach-mvebu/hotplug.c                      |   30 +++++
 arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++-
 arch/arm/mach-mvebu/platsmp.c                      |  124 ++++++++++++++++++++
 arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++
 arch/arm/mach-mvebu/pmsu.h                         |   16 +++
 arch/arm/mm/Kconfig                                |    4 +
 arch/arm/mm/proc-v7.S                              |   46 ++++++++
 21 files changed, 648 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
 create mode 100644 arch/arm/mach-mvebu/coherency.c
 create mode 100644 arch/arm/mach-mvebu/coherency.h
 create mode 100644 arch/arm/mach-mvebu/headsmp.S
 create mode 100644 arch/arm/mach-mvebu/hotplug.c
 create mode 100644 arch/arm/mach-mvebu/platsmp.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.h

-- 
1.7.9.5

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/coherency-fabric.txt   |   16 ++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 ++
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++++++++
 arch/arm/mach-mvebu/coherency.h                    |   21 +++++
 arch/arm/mach-mvebu/common.h                       |    2 +
 6 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
 create mode 100644 arch/arm/mach-mvebu/coherency.c
 create mode 100644 arch/arm/mach-mvebu/coherency.h

diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
new file mode 100644
index 0000000..2bfbf67
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -0,0 +1,16 @@
+Coherency fabric
+----------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,coherency-fabric"
+- reg: Should contain,coherency fabric registers location and length.
+
+Example:
+
+coherency-fabric@d0020200 {
+	compatible = "marvell,coherency-fabric";
+	reg = <0xd0020200 0xb0>;
+};
+
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..b0d075b 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -36,6 +36,11 @@
 	      interrupt-controller;
 	};
 
+	coherency-fabric@d0020200 {
+		compatible = "marvell,coherency-fabric";
+		reg = <0xd0020200 0xb0>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 57f996b..abd6d3b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-orion/include
 
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
new file mode 100644
index 0000000..69e130d
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -0,0 +1,89 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada 370 and Armada XP SOCs have a coherency fabric which is
+ * responsible for ensuring hardware coherency between all CPUs and between
+ * CPUs and I/O masters. This file initializes the coherency fabric and
+ * supplies basic routines for configuring and controlling hardware coherency
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+#include "armada-370-xp.h"
+
+/* Some functions in this file are called very early during SMP
+ * initialization. At that time the device tree framework is not yet
+ * ready, and it is not possible to get the register address to
+ * ioremap it. That's why the pointer below is given with an initial
+ * value matching its virtual mapping
+ */
+static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE + 0x20200;
+
+/* Coherency fabric registers */
+#define COHERENCY_FABRIC_CTL_OFFSET		   0x0
+#define COHERENCY_FABRIC_CFG_OFFSET		   0x4
+
+static struct of_device_id of_coherency_table[] = {
+	{.compatible = "marvell,coherency-fabric"},
+	{ /* end of list */ },
+};
+
+int coherency_get_cpu_count(void)
+{
+	int reg, cnt;
+
+	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+	cnt = (reg & 0xF) + 1;
+
+	return cnt;
+}
+
+int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
+{
+	int reg;
+
+	if (!coherency_base) {
+		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
+		pr_warn("Coherency fabric is not initialized\n");
+		return 1;
+	}
+
+	/* Enable the CPU in coherency fabric */
+	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+	reg |= 1 << (24 + hw_cpu_id);
+	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+
+	/* Add CPU to SMP group */
+	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
+	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+
+	return 0;
+}
+
+int __init coherency_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, of_coherency_table);
+	if (np) {
+		pr_info("Initializing Coherency fabric\n");
+		coherency_base = of_iomap(np, 0);
+	}
+
+	return 0;
+}
diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
new file mode 100644
index 0000000..6182192
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.h
@@ -0,0 +1,21 @@
+/*
+ * arch/arm/mach-mvebu/include/mach/coherency.h
+ *
+ *
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_370_XP_COHERENCY_H
+#define __MACH_370_XP_COHERENCY_H
+
+int set_cpu_coherent(int cpu_id, int smp_group_id);
+int coherency_get_cpu_count(void);
+int coherency_init(void);
+
+#endif	/* __MACH_370_XP_COHERENCY_H */
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 281fab3..ea08919 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,4 +21,6 @@ void mvebu_clocks_init(void);
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
 
+
+int armada_370_xp_coherency_init(void);
 #endif
-- 
1.7.9.5

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/coherency-fabric.txt   |   16 ++++
 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 ++
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++++++++
 arch/arm/mach-mvebu/coherency.h                    |   21 +++++
 arch/arm/mach-mvebu/common.h                       |    2 +
 6 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
 create mode 100644 arch/arm/mach-mvebu/coherency.c
 create mode 100644 arch/arm/mach-mvebu/coherency.h

diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
new file mode 100644
index 0000000..2bfbf67
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -0,0 +1,16 @@
+Coherency fabric
+----------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,coherency-fabric"
+- reg: Should contain,coherency fabric registers location and length.
+
+Example:
+
+coherency-fabric at d0020200 {
+	compatible = "marvell,coherency-fabric";
+	reg = <0xd0020200 0xb0>;
+};
+
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..b0d075b 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -36,6 +36,11 @@
 	      interrupt-controller;
 	};
 
+	coherency-fabric at d0020200 {
+		compatible = "marvell,coherency-fabric";
+		reg = <0xd0020200 0xb0>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 57f996b..abd6d3b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-orion/include
 
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
new file mode 100644
index 0000000..69e130d
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -0,0 +1,89 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada 370 and Armada XP SOCs have a coherency fabric which is
+ * responsible for ensuring hardware coherency between all CPUs and between
+ * CPUs and I/O masters. This file initializes the coherency fabric and
+ * supplies basic routines for configuring and controlling hardware coherency
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+#include "armada-370-xp.h"
+
+/* Some functions in this file are called very early during SMP
+ * initialization. At that time the device tree framework is not yet
+ * ready, and it is not possible to get the register address to
+ * ioremap it. That's why the pointer below is given with an initial
+ * value matching its virtual mapping
+ */
+static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE + 0x20200;
+
+/* Coherency fabric registers */
+#define COHERENCY_FABRIC_CTL_OFFSET		   0x0
+#define COHERENCY_FABRIC_CFG_OFFSET		   0x4
+
+static struct of_device_id of_coherency_table[] = {
+	{.compatible = "marvell,coherency-fabric"},
+	{ /* end of list */ },
+};
+
+int coherency_get_cpu_count(void)
+{
+	int reg, cnt;
+
+	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+	cnt = (reg & 0xF) + 1;
+
+	return cnt;
+}
+
+int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
+{
+	int reg;
+
+	if (!coherency_base) {
+		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
+		pr_warn("Coherency fabric is not initialized\n");
+		return 1;
+	}
+
+	/* Enable the CPU in coherency fabric */
+	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+	reg |= 1 << (24 + hw_cpu_id);
+	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
+
+	/* Add CPU to SMP group */
+	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
+	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
+
+	return 0;
+}
+
+int __init coherency_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, of_coherency_table);
+	if (np) {
+		pr_info("Initializing Coherency fabric\n");
+		coherency_base = of_iomap(np, 0);
+	}
+
+	return 0;
+}
diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
new file mode 100644
index 0000000..6182192
--- /dev/null
+++ b/arch/arm/mach-mvebu/coherency.h
@@ -0,0 +1,21 @@
+/*
+ * arch/arm/mach-mvebu/include/mach/coherency.h
+ *
+ *
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_370_XP_COHERENCY_H
+#define __MACH_370_XP_COHERENCY_H
+
+int set_cpu_coherent(int cpu_id, int smp_group_id);
+int coherency_get_cpu_count(void);
+int coherency_init(void);
+
+#endif	/* __MACH_370_XP_COHERENCY_H */
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 281fab3..ea08919 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,4 +21,6 @@ void mvebu_clocks_init(void);
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
 
+
+int armada_370_xp_coherency_init(void);
 #endif
-- 
1.7.9.5

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

Hi Gregory,

On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> new file mode 100644
> index 0000000..69e130d
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -0,0 +1,89 @@
> +/*
> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
> + * responsible for ensuring hardware coherency between all CPUs and between
> + * CPUs and I/O masters. This file initializes the coherency fabric and
> + * supplies basic routines for configuring and controlling hardware coherency
> + */

[...]

> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> +{
> +	int reg;
> +
> +	if (!coherency_base) {
> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> +		pr_warn("Coherency fabric is not initialized\n");
> +		return 1;
> +	}
> +
> +	/* Enable the CPU in coherency fabric */
> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> +	reg |= 1 << (24 + hw_cpu_id);
> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> +
> +	/* Add CPU to SMP group */
> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> +
> +	return 0;
> +}

These writels may expand to code containing calls to outer_sync(), which
will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
coherent, how does this play out with the exclusive store instruction in the
lock?

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

Hi Gregory,

On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> new file mode 100644
> index 0000000..69e130d
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -0,0 +1,89 @@
> +/*
> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
> + * responsible for ensuring hardware coherency between all CPUs and between
> + * CPUs and I/O masters. This file initializes the coherency fabric and
> + * supplies basic routines for configuring and controlling hardware coherency
> + */

[...]

> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> +{
> +	int reg;
> +
> +	if (!coherency_base) {
> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> +		pr_warn("Coherency fabric is not initialized\n");
> +		return 1;
> +	}
> +
> +	/* Enable the CPU in coherency fabric */
> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> +	reg |= 1 << (24 + hw_cpu_id);
> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> +
> +	/* Add CPU to SMP group */
> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> +
> +	return 0;
> +}

These writels may expand to code containing calls to outer_sync(), which
will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
coherent, how does this play out with the exclusive store instruction in the
lock?

Will

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,

Hi Will,

> 
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
> 
> [...]
> 
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> +	int reg;
>> +
>> +	if (!coherency_base) {
>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> +		pr_warn("Coherency fabric is not initialized\n");
>> +		return 1;
>> +	}
>> +
>> +	/* Enable the CPU in coherency fabric */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +	reg |= 1 << (24 + hw_cpu_id);
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> +	/* Add CPU to SMP group */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> +	return 0;
>> +}
> 
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?

I forward this question to the Marvell experts.

> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,

Hi Will,

> 
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
> 
> [...]
> 
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> +	int reg;
>> +
>> +	if (!coherency_base) {
>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> +		pr_warn("Coherency fabric is not initialized\n");
>> +		return 1;
>> +	}
>> +
>> +	/* Enable the CPU in coherency fabric */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +	reg |= 1 << (24 + hw_cpu_id);
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> +	/* Add CPU to SMP group */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> +	return 0;
>> +}
> 
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?

I forward this question to the Marvell experts.

> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

Hi Will,

On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,
> 
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
> 
> [...]
> 
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> +	int reg;
>> +
>> +	if (!coherency_base) {
>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> +		pr_warn("Coherency fabric is not initialized\n");
>> +		return 1;
>> +	}
>> +
>> +	/* Enable the CPU in coherency fabric */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +	reg |= 1 << (24 + hw_cpu_id);
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> +	/* Add CPU to SMP group */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> +	return 0;
>> +}
> 
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?

I dug a little this subject: and I am not sure there is problem. In SMP mode,
only the system cache mode of Aurora is used. In this mode, outer_cache.sync
is void then outer_sync() won't call any function, so there will be no
access to any spinlock.

Gregory

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

Hi Will,

On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,
> 
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
> 
> [...]
> 
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> +	int reg;
>> +
>> +	if (!coherency_base) {
>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> +		pr_warn("Coherency fabric is not initialized\n");
>> +		return 1;
>> +	}
>> +
>> +	/* Enable the CPU in coherency fabric */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +	reg |= 1 << (24 + hw_cpu_id);
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> +	/* Add CPU to SMP group */
>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> +	return 0;
>> +}
> 
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?

I dug a little this subject: and I am not sure there is problem. In SMP mode,
only the system cache mode of Aurora is used. In this mode, outer_cache.sync
is void then outer_sync() won't call any function, so there will be no
access to any spinlock.

Gregory

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
> On 11/05/2012 03:02 PM, Will Deacon wrote:
> > On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> >> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> >> +{
> >> +	int reg;
> >> +
> >> +	if (!coherency_base) {
> >> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> >> +		pr_warn("Coherency fabric is not initialized\n");
> >> +		return 1;
> >> +	}
> >> +
> >> +	/* Enable the CPU in coherency fabric */
> >> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> +	reg |= 1 << (24 + hw_cpu_id);
> >> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> +
> >> +	/* Add CPU to SMP group */
> >> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> >> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> +
> >> +	return 0;
> >> +}
> > 
> > These writels may expand to code containing calls to outer_sync(), which
> > will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> > coherent, how does this play out with the exclusive store instruction in the
> > lock?
> 
> I dug a little this subject: and I am not sure there is problem. In SMP mode,
> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
> is void then outer_sync() won't call any function, so there will be no
> access to any spinlock.

Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
printk takes logbuf_lock, for example, and I'm sure that by the time you get
to this code you will have relied on exclusives behaving correctly.

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
> On 11/05/2012 03:02 PM, Will Deacon wrote:
> > On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> >> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> >> +{
> >> +	int reg;
> >> +
> >> +	if (!coherency_base) {
> >> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> >> +		pr_warn("Coherency fabric is not initialized\n");
> >> +		return 1;
> >> +	}
> >> +
> >> +	/* Enable the CPU in coherency fabric */
> >> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> +	reg |= 1 << (24 + hw_cpu_id);
> >> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> +
> >> +	/* Add CPU to SMP group */
> >> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> >> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> +
> >> +	return 0;
> >> +}
> > 
> > These writels may expand to code containing calls to outer_sync(), which
> > will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> > coherent, how does this play out with the exclusive store instruction in the
> > lock?
> 
> I dug a little this subject: and I am not sure there is problem. In SMP mode,
> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
> is void then outer_sync() won't call any function, so there will be no
> access to any spinlock.

Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
printk takes logbuf_lock, for example, and I'm sure that by the time you get
to this code you will have relied on exclusives behaving correctly.

Will

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/13/2012 11:43 AM, Will Deacon wrote:
> On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
>> On 11/05/2012 03:02 PM, Will Deacon wrote:
>>> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>>>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>>>> +{
>>>> +	int reg;
>>>> +
>>>> +	if (!coherency_base) {
>>>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>>>> +		pr_warn("Coherency fabric is not initialized\n");
>>>> +		return 1;
>>>> +	}
>>>> +
>>>> +	/* Enable the CPU in coherency fabric */
>>>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>>>> +	reg |= 1 << (24 + hw_cpu_id);
>>>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>>>> +
>>>> +	/* Add CPU to SMP group */
>>>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>>>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>>>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> These writels may expand to code containing calls to outer_sync(), which
>>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
>>> coherent, how does this play out with the exclusive store instruction in the
>>> lock?
>>
>> I dug a little this subject: and I am not sure there is problem. In SMP mode,
>> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
>> is void then outer_sync() won't call any function, so there will be no
>> access to any spinlock.
> 
> Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
> printk takes logbuf_lock, for example, and I'm sure that by the time you get
> to this code you will have relied on exclusives behaving correctly.
> 

Hi Will,
I get an answer from Marvell engineers:
"STREX on non-shareable and/or non-cacheable memory regions is supported."

Gregory

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/13/2012 11:43 AM, Will Deacon wrote:
> On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
>> On 11/05/2012 03:02 PM, Will Deacon wrote:
>>> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>>>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>>>> +{
>>>> +	int reg;
>>>> +
>>>> +	if (!coherency_base) {
>>>> +		pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>>>> +		pr_warn("Coherency fabric is not initialized\n");
>>>> +		return 1;
>>>> +	}
>>>> +
>>>> +	/* Enable the CPU in coherency fabric */
>>>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>>>> +	reg |= 1 << (24 + hw_cpu_id);
>>>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>>>> +
>>>> +	/* Add CPU to SMP group */
>>>> +	reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>>>> +	reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>>>> +	writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> These writels may expand to code containing calls to outer_sync(), which
>>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
>>> coherent, how does this play out with the exclusive store instruction in the
>>> lock?
>>
>> I dug a little this subject: and I am not sure there is problem. In SMP mode,
>> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
>> is void then outer_sync() won't call any function, so there will be no
>> access to any spinlock.
> 
> Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
> printk takes logbuf_lock, for example, and I'm sure that by the time you get
> to this code you will have relied on exclusives behaving correctly.
> 

Hi Will,
I get an answer from Marvell engineers:
"STREX on non-shareable and/or non-cacheable memory regions is supported."

Gregory

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Wed, Nov 14, 2012 at 08:00:32PM +0000, Gregory CLEMENT wrote:
> On 11/13/2012 11:43 AM, Will Deacon wrote:
> > On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
> >> On 11/05/2012 03:02 PM, Will Deacon wrote:
> >>> These writels may expand to code containing calls to outer_sync(), which
> >>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> >>> coherent, how does this play out with the exclusive store instruction in the
> >>> lock?
> >>
> >> I dug a little this subject: and I am not sure there is problem. In SMP mode,
> >> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
> >> is void then outer_sync() won't call any function, so there will be no
> >> access to any spinlock.
> > 
> > Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
> > printk takes logbuf_lock, for example, and I'm sure that by the time you get
> > to this code you will have relied on exclusives behaving correctly.
> > 
> 
> Hi Will,
> I get an answer from Marvell engineers:
> "STREX on non-shareable and/or non-cacheable memory regions is supported."

Interesting, thanks for asking them about this. Does this mean that:

	1. When not running coherently (i.e. before initialising the
	   coherency fabric), memory is treated as non-shareable,
	   non-cacheable?

	2. If (1), then are exclusive accesses the only way to achieve
	   coherent memory accesses in this scenario?

If so, you still have a problem with write locks, where the unlock code does
a regular str to clear the status. atomic_{read,set} also uses regular
memory accesses, so I think you'll get some surprises there when you add
explicit memory barriers and expect things to be visible between threads.

Do memory barriers have different semantics depending on the state of your
coherency fabric?

Cheers,

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Wed, Nov 14, 2012 at 08:00:32PM +0000, Gregory CLEMENT wrote:
> On 11/13/2012 11:43 AM, Will Deacon wrote:
> > On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
> >> On 11/05/2012 03:02 PM, Will Deacon wrote:
> >>> These writels may expand to code containing calls to outer_sync(), which
> >>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> >>> coherent, how does this play out with the exclusive store instruction in the
> >>> lock?
> >>
> >> I dug a little this subject: and I am not sure there is problem. In SMP mode,
> >> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
> >> is void then outer_sync() won't call any function, so there will be no
> >> access to any spinlock.
> > 
> > Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
> > printk takes logbuf_lock, for example, and I'm sure that by the time you get
> > to this code you will have relied on exclusives behaving correctly.
> > 
> 
> Hi Will,
> I get an answer from Marvell engineers:
> "STREX on non-shareable and/or non-cacheable memory regions is supported."

Interesting, thanks for asking them about this. Does this mean that:

	1. When not running coherently (i.e. before initialising the
	   coherency fabric), memory is treated as non-shareable,
	   non-cacheable?

	2. If (1), then are exclusive accesses the only way to achieve
	   coherent memory accesses in this scenario?

If so, you still have a problem with write locks, where the unlock code does
a regular str to clear the status. atomic_{read,set} also uses regular
memory accesses, so I think you'll get some surprises there when you add
explicit memory barriers and expect things to be visible between threads.

Do memory barriers have different semantics depending on the state of your
coherency fabric?

Cheers,

Will

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/15/2012 11:17 AM, Will Deacon wrote:
> On Wed, Nov 14, 2012 at 08:00:32PM +0000, Gregory CLEMENT wrote:
>> On 11/13/2012 11:43 AM, Will Deacon wrote:
>>> On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
>>>> On 11/05/2012 03:02 PM, Will Deacon wrote:
>>>>> These writels may expand to code containing calls to outer_sync(), which
>>>>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
>>>>> coherent, how does this play out with the exclusive store instruction in the
>>>>> lock?
>>>>
>>>> I dug a little this subject: and I am not sure there is problem. In SMP mode,
>>>> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
>>>> is void then outer_sync() won't call any function, so there will be no
>>>> access to any spinlock.
>>>
>>> Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
>>> printk takes logbuf_lock, for example, and I'm sure that by the time you get
>>> to this code you will have relied on exclusives behaving correctly.
>>>
>>
>> Hi Will,
>> I get an answer from Marvell engineers:
>> "STREX on non-shareable and/or non-cacheable memory regions is supported."
> 
> Interesting, thanks for asking them about this. Does this mean that:

Here come the answers to your new questions


>
> 	1. When not running coherently (i.e. before initialising the
> 	   coherency fabric), memory is treated as non-shareable,
> 	   non-cacheable?

It can be cacheable. The shared memory (as defined on the page table)
will NOT be coherent by HW.

>
> 	2. If (1), then are exclusive accesses the only way to achieve
> 	   coherent memory accesses in this scenario?

I quote: "I suspect there is terminology miss-use: exclusive accesses
are NOT used to achieve memory coherency - they are used to achieve
atomicity. To achieve memory coherency while fabric is configured to
be non-coherent, SW should use maintenance operations over the L1
caches.suspect there is terminology miss-use: exclusive accesses are
NOT used to achieve memory coherency - "they are used to achieve
atomicity. To achieve memory coherency while fabric is configured to
be non-coherent, SW should use maintenance operations over the L1
caches.

> If so, you still have a problem with write locks, where the unlock code does
> a regular str to clear the status. atomic_{read,set} also uses regular
> memory accesses, so I think you'll get some surprises there when you add
> explicit memory barriers and expect things to be visible between threads.
>
> Do memory barriers have different semantics depending on the state of your
> coherency fabric?

No


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/15/2012 11:17 AM, Will Deacon wrote:
> On Wed, Nov 14, 2012 at 08:00:32PM +0000, Gregory CLEMENT wrote:
>> On 11/13/2012 11:43 AM, Will Deacon wrote:
>>> On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
>>>> On 11/05/2012 03:02 PM, Will Deacon wrote:
>>>>> These writels may expand to code containing calls to outer_sync(), which
>>>>> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
>>>>> coherent, how does this play out with the exclusive store instruction in the
>>>>> lock?
>>>>
>>>> I dug a little this subject: and I am not sure there is problem. In SMP mode,
>>>> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
>>>> is void then outer_sync() won't call any function, so there will be no
>>>> access to any spinlock.
>>>
>>> Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
>>> printk takes logbuf_lock, for example, and I'm sure that by the time you get
>>> to this code you will have relied on exclusives behaving correctly.
>>>
>>
>> Hi Will,
>> I get an answer from Marvell engineers:
>> "STREX on non-shareable and/or non-cacheable memory regions is supported."
> 
> Interesting, thanks for asking them about this. Does this mean that:

Here come the answers to your new questions


>
> 	1. When not running coherently (i.e. before initialising the
> 	   coherency fabric), memory is treated as non-shareable,
> 	   non-cacheable?

It can be cacheable. The shared memory (as defined on the page table)
will NOT be coherent by HW.

>
> 	2. If (1), then are exclusive accesses the only way to achieve
> 	   coherent memory accesses in this scenario?

I quote: "I suspect there is terminology miss-use: exclusive accesses
are NOT used to achieve memory coherency - they are used to achieve
atomicity. To achieve memory coherency while fabric is configured to
be non-coherent, SW should use maintenance operations over the L1
caches.suspect there is terminology miss-use: exclusive accesses are
NOT used to achieve memory coherency - "they are used to achieve
atomicity. To achieve memory coherency while fabric is configured to
be non-coherent, SW should use maintenance operations over the L1
caches.

> If so, you still have a problem with write locks, where the unlock code does
> a regular str to clear the status. atomic_{read,set} also uses regular
> memory accesses, so I think you'll get some surprises there when you add
> explicit memory barriers and expect things to be visible between threads.
>
> Do memory barriers have different semantics depending on the state of your
> coherency fabric?

No


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

Hi Gregory,

On Thu, Nov 15, 2012 at 03:54:39PM +0000, Gregory CLEMENT wrote:
> On 11/15/2012 11:17 AM, Will Deacon wrote:
> > Interesting, thanks for asking them about this. Does this mean that:
> 
> Here come the answers to your new questions

Great, thanks for the quick turn-around!

> > 	1. When not running coherently (i.e. before initialising the
> > 	   coherency fabric), memory is treated as non-shareable,
> > 	   non-cacheable?
> 
> It can be cacheable. The shared memory (as defined on the page table)
> will NOT be coherent by HW.

Ok, so we really are incoherent before enabling the fabric.

> > 	2. If (1), then are exclusive accesses the only way to achieve
> > 	   coherent memory accesses in this scenario?
> 
> I quote: "I suspect there is terminology miss-use: exclusive accesses
> are NOT used to achieve memory coherency - they are used to achieve
> atomicity. To achieve memory coherency while fabric is configured to
> be non-coherent, SW should use maintenance operations over the L1
> caches."

Ok, so if I'm understanding correctly then I don't really see the usefulness
of having working exclusives that are incoherent. Surely it means that you
can guarantee mutual exclusion on a lock variable, but the value you actually
end up reading from the lock is junk unless you litter the accessors with cache
clean operations?

Anyway, that's by-the-by as this is all called early enough that we
shouldn't care. The thing I don't like now is that the fabric initialisation
is done entirely differently on the primary CPU than the secondaries. The
primary probes the device-tree (well, it's also now hard-coded for v2) and
accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
the secondaries have hardcoded addresses and access via asm
(armada_xp_secondary_startup).

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

Hi Gregory,

On Thu, Nov 15, 2012 at 03:54:39PM +0000, Gregory CLEMENT wrote:
> On 11/15/2012 11:17 AM, Will Deacon wrote:
> > Interesting, thanks for asking them about this. Does this mean that:
> 
> Here come the answers to your new questions

Great, thanks for the quick turn-around!

> > 	1. When not running coherently (i.e. before initialising the
> > 	   coherency fabric), memory is treated as non-shareable,
> > 	   non-cacheable?
> 
> It can be cacheable. The shared memory (as defined on the page table)
> will NOT be coherent by HW.

Ok, so we really are incoherent before enabling the fabric.

> > 	2. If (1), then are exclusive accesses the only way to achieve
> > 	   coherent memory accesses in this scenario?
> 
> I quote: "I suspect there is terminology miss-use: exclusive accesses
> are NOT used to achieve memory coherency - they are used to achieve
> atomicity. To achieve memory coherency while fabric is configured to
> be non-coherent, SW should use maintenance operations over the L1
> caches."

Ok, so if I'm understanding correctly then I don't really see the usefulness
of having working exclusives that are incoherent. Surely it means that you
can guarantee mutual exclusion on a lock variable, but the value you actually
end up reading from the lock is junk unless you litter the accessors with cache
clean operations?

Anyway, that's by-the-by as this is all called early enough that we
shouldn't care. The thing I don't like now is that the fabric initialisation
is done entirely differently on the primary CPU than the secondaries. The
primary probes the device-tree (well, it's also now hard-coded for v2) and
accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
the secondaries have hardcoded addresses and access via asm
(armada_xp_secondary_startup).

Will

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/15/2012 05:21 PM, Will Deacon wrote:
> Hi Gregory,
> 
> On Thu, Nov 15, 2012 at 03:54:39PM +0000, Gregory CLEMENT wrote:
>> On 11/15/2012 11:17 AM, Will Deacon wrote:
>>> Interesting, thanks for asking them about this. Does this mean that:
>>
>> Here come the answers to your new questions
> 
> Great, thanks for the quick turn-around!
> 
>>> 	1. When not running coherently (i.e. before initialising the
>>> 	   coherency fabric), memory is treated as non-shareable,
>>> 	   non-cacheable?
>>
>> It can be cacheable. The shared memory (as defined on the page table)
>> will NOT be coherent by HW.
> 
> Ok, so we really are incoherent before enabling the fabric.
> 
>>> 	2. If (1), then are exclusive accesses the only way to achieve
>>> 	   coherent memory accesses in this scenario?
>>
>> I quote: "I suspect there is terminology miss-use: exclusive accesses
>> are NOT used to achieve memory coherency - they are used to achieve
>> atomicity. To achieve memory coherency while fabric is configured to
>> be non-coherent, SW should use maintenance operations over the L1
>> caches."
> 
> Ok, so if I'm understanding correctly then I don't really see the usefulness
> of having working exclusives that are incoherent. Surely it means that you
> can guarantee mutual exclusion on a lock variable, but the value you actually
> end up reading from the lock is junk unless you litter the accessors with cache
> clean operations?
> 
> Anyway, that's by-the-by as this is all called early enough that we
> shouldn't care. The thing I don't like now is that the fabric initialisation
> is done entirely differently on the primary CPU than the secondaries. The
> primary probes the device-tree (well, it's also now hard-coded for v2) and
> accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
> the secondaries have hardcoded addresses and access via asm
> (armada_xp_secondary_startup).


Now it is hardcoded in both case as you pointed it. So the last
difference is setup from a C function or via asm.

The differences between primary and secondary CPU when they enable the
coherency, is due to the fact that we really are in a different
situation. For primary CPU, as it is the only CPU online it doesn't
need to enable the coherency from the beginning, so we can wait to
have MMU enable and convenient feature. Whereas for the secondary CPU
they need the coherency from the very beginning are by definition they
won't be alone. That's why this very first instruction are written in
asm and they use physical address.

I don't see how to handle it in a different way.

Gregory

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/15/2012 05:21 PM, Will Deacon wrote:
> Hi Gregory,
> 
> On Thu, Nov 15, 2012 at 03:54:39PM +0000, Gregory CLEMENT wrote:
>> On 11/15/2012 11:17 AM, Will Deacon wrote:
>>> Interesting, thanks for asking them about this. Does this mean that:
>>
>> Here come the answers to your new questions
> 
> Great, thanks for the quick turn-around!
> 
>>> 	1. When not running coherently (i.e. before initialising the
>>> 	   coherency fabric), memory is treated as non-shareable,
>>> 	   non-cacheable?
>>
>> It can be cacheable. The shared memory (as defined on the page table)
>> will NOT be coherent by HW.
> 
> Ok, so we really are incoherent before enabling the fabric.
> 
>>> 	2. If (1), then are exclusive accesses the only way to achieve
>>> 	   coherent memory accesses in this scenario?
>>
>> I quote: "I suspect there is terminology miss-use: exclusive accesses
>> are NOT used to achieve memory coherency - they are used to achieve
>> atomicity. To achieve memory coherency while fabric is configured to
>> be non-coherent, SW should use maintenance operations over the L1
>> caches."
> 
> Ok, so if I'm understanding correctly then I don't really see the usefulness
> of having working exclusives that are incoherent. Surely it means that you
> can guarantee mutual exclusion on a lock variable, but the value you actually
> end up reading from the lock is junk unless you litter the accessors with cache
> clean operations?
> 
> Anyway, that's by-the-by as this is all called early enough that we
> shouldn't care. The thing I don't like now is that the fabric initialisation
> is done entirely differently on the primary CPU than the secondaries. The
> primary probes the device-tree (well, it's also now hard-coded for v2) and
> accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
> the secondaries have hardcoded addresses and access via asm
> (armada_xp_secondary_startup).


Now it is hardcoded in both case as you pointed it. So the last
difference is setup from a C function or via asm.

The differences between primary and secondary CPU when they enable the
coherency, is due to the fact that we really are in a different
situation. For primary CPU, as it is the only CPU online it doesn't
need to enable the coherency from the beginning, so we can wait to
have MMU enable and convenient feature. Whereas for the secondary CPU
they need the coherency from the very beginning are by definition they
won't be alone. That's why this very first instruction are written in
asm and they use physical address.

I don't see how to handle it in a different way.

Gregory

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Thu, Nov 15, 2012 at 04:49:17PM +0000, Gregory CLEMENT wrote:
> On 11/15/2012 05:21 PM, Will Deacon wrote:
> > Anyway, that's by-the-by as this is all called early enough that we
> > shouldn't care. The thing I don't like now is that the fabric initialisation
> > is done entirely differently on the primary CPU than the secondaries. The
> > primary probes the device-tree (well, it's also now hard-coded for v2) and
> > accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
> > the secondaries have hardcoded addresses and access via asm
> > (armada_xp_secondary_startup).
> 
> 
> Now it is hardcoded in both case as you pointed it. So the last
> difference is setup from a C function or via asm.
> 
> The differences between primary and secondary CPU when they enable the
> coherency, is due to the fact that we really are in a different
> situation. For primary CPU, as it is the only CPU online it doesn't
> need to enable the coherency from the beginning, so we can wait to
> have MMU enable and convenient feature. Whereas for the secondary CPU
> they need the coherency from the very beginning are by definition they
> won't be alone. That's why this very first instruction are written in
> asm and they use physical address.
> 
> I don't see how to handle it in a different way.

The code paths are fine, I would just like to see less duplication. Can you
make the asm function PCS compliant and call it from C for the primary
(setting the link register to secondary_startup for the secondary cores)?

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Thu, Nov 15, 2012 at 04:49:17PM +0000, Gregory CLEMENT wrote:
> On 11/15/2012 05:21 PM, Will Deacon wrote:
> > Anyway, that's by-the-by as this is all called early enough that we
> > shouldn't care. The thing I don't like now is that the fabric initialisation
> > is done entirely differently on the primary CPU than the secondaries. The
> > primary probes the device-tree (well, it's also now hard-coded for v2) and
> > accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
> > the secondaries have hardcoded addresses and access via asm
> > (armada_xp_secondary_startup).
> 
> 
> Now it is hardcoded in both case as you pointed it. So the last
> difference is setup from a C function or via asm.
> 
> The differences between primary and secondary CPU when they enable the
> coherency, is due to the fact that we really are in a different
> situation. For primary CPU, as it is the only CPU online it doesn't
> need to enable the coherency from the beginning, so we can wait to
> have MMU enable and convenient feature. Whereas for the secondary CPU
> they need the coherency from the very beginning are by definition they
> won't be alone. That's why this very first instruction are written in
> asm and they use physical address.
> 
> I don't see how to handle it in a different way.

The code paths are fine, I would just like to see less duplication. Can you
make the asm function PCS compliant and call it from C for the primary
(setting the link register to secondary_startup for the secondary cores)?

Will

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/16/2012 07:56 PM, Will Deacon wrote:
> On Thu, Nov 15, 2012 at 04:49:17PM +0000, Gregory CLEMENT wrote:
>> On 11/15/2012 05:21 PM, Will Deacon wrote:
>>> Anyway, that's by-the-by as this is all called early enough that we
>>> shouldn't care. The thing I don't like now is that the fabric initialisation
>>> is done entirely differently on the primary CPU than the secondaries. The
>>> primary probes the device-tree (well, it's also now hard-coded for v2) and
>>> accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
>>> the secondaries have hardcoded addresses and access via asm
>>> (armada_xp_secondary_startup).
>>
>>
>> Now it is hardcoded in both case as you pointed it. So the last
>> difference is setup from a C function or via asm.
>>
>> The differences between primary and secondary CPU when they enable the
>> coherency, is due to the fact that we really are in a different
>> situation. For primary CPU, as it is the only CPU online it doesn't
>> need to enable the coherency from the beginning, so we can wait to
>> have MMU enable and convenient feature. Whereas for the secondary CPU
>> they need the coherency from the very beginning are by definition they
>> won't be alone. That's why this very first instruction are written in
>> asm and they use physical address.
>>
>> I don't see how to handle it in a different way.
> 
> The code paths are fine, I would just like to see less duplication. Can you
> make the asm function PCS compliant and call it from C for the primary
> (setting the link register to secondary_startup for the secondary cores)?

Have you a pointer on how to do it (make the asm function PCS compliant)?

I will also need to add a parameter, because the base address are not the
same between primary CPU and secondary CPUS. With the first we use virtual
address whereas with the second the physical address.


> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Gregory CLEMENT]

On 11/16/2012 07:56 PM, Will Deacon wrote:
> On Thu, Nov 15, 2012 at 04:49:17PM +0000, Gregory CLEMENT wrote:
>> On 11/15/2012 05:21 PM, Will Deacon wrote:
>>> Anyway, that's by-the-by as this is all called early enough that we
>>> shouldn't care. The thing I don't like now is that the fabric initialisation
>>> is done entirely differently on the primary CPU than the secondaries. The
>>> primary probes the device-tree (well, it's also now hard-coded for v2) and
>>> accesses the registers from a C function(armada_370_xp_set_cpu_coherent) whilst
>>> the secondaries have hardcoded addresses and access via asm
>>> (armada_xp_secondary_startup).
>>
>>
>> Now it is hardcoded in both case as you pointed it. So the last
>> difference is setup from a C function or via asm.
>>
>> The differences between primary and secondary CPU when they enable the
>> coherency, is due to the fact that we really are in a different
>> situation. For primary CPU, as it is the only CPU online it doesn't
>> need to enable the coherency from the beginning, so we can wait to
>> have MMU enable and convenient feature. Whereas for the secondary CPU
>> they need the coherency from the very beginning are by definition they
>> won't be alone. That's why this very first instruction are written in
>> asm and they use physical address.
>>
>> I don't see how to handle it in a different way.
> 
> The code paths are fine, I would just like to see less duplication. Can you
> make the asm function PCS compliant and call it from C for the primary
> (setting the link register to secondary_startup for the secondary cores)?

Have you a pointer on how to do it (make the asm function PCS compliant)?

I will also need to add a parameter, because the base address are not the
same between primary CPU and secondary CPUS. With the first we use virtual
address whereas with the second the physical address.


> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Fri, Nov 16, 2012 at 07:25:53PM +0000, Gregory CLEMENT wrote:
> On 11/16/2012 07:56 PM, Will Deacon wrote:
> > 
> > The code paths are fine, I would just like to see less duplication. Can you
> > make the asm function PCS compliant and call it from C for the primary
> > (setting the link register to secondary_startup for the secondary cores)?
> 
> Have you a pointer on how to do it (make the asm function PCS compliant)?

Take a look at the PCS document:

  http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

For your case it's really simple though as you don't need to use the stack:
just take the base address in r0 and use a subset of r1-r3 for temporaries
while setting up the control registers. Then mov pc, lr at the end.

> I will also need to add a parameter, because the base address are not the
> same between primary CPU and secondary CPUS. With the first we use virtual
> address whereas with the second the physical address.

Should be simple enough to add a secondary entry point immediately before,
which initialises r0 and lr.

Will

[PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu

[Will Deacon]

On Fri, Nov 16, 2012 at 07:25:53PM +0000, Gregory CLEMENT wrote:
> On 11/16/2012 07:56 PM, Will Deacon wrote:
> > 
> > The code paths are fine, I would just like to see less duplication. Can you
> > make the asm function PCS compliant and call it from C for the primary
> > (setting the link register to secondary_startup for the secondary cores)?
> 
> Have you a pointer on how to do it (make the asm function PCS compliant)?

Take a look at the PCS document:

  http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

For your case it's really simple though as you don't need to use the stack:
just take the base address in r0 and use a subset of r1-r3 for temporaries
while setting up the control registers. Then mov pc, lr at the end.

> I will also need to add a parameter, because the base address are not the
> same between primary CPU and secondary CPUS. With the first we use virtual
> address whereas with the second the physical address.

Should be simple enough to add a secondary entry point immediately before,
which initialises r0 and lr.

Will

[PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 +++++
 arch/arm/boot/dts/armada-xp.dtsi                   |    6 ++
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/common.h                       |    1 +
 arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++++++++++
 arch/arm/mach-mvebu/pmsu.h                         |   16 ++++
 6 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
 create mode 100644 arch/arm/mach-mvebu/pmsu.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.h

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
new file mode 100644
index 0000000..926b4d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
@@ -0,0 +1,20 @@
+Power Management Service Unit(PMSU)
+-----------------------------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,armada-370-xp-pmsu"
+
+- reg: Should contain PMSU registers location and length. First pair
+  for the per-CPU SW Reset Control registers, second pair for the
+  Power Management Service Unit.
+
+Example:
+
+armada-370-xp-pmsu@d0022000 {
+	compatible = "marvell,armada-370-xp-pmsu";
+	reg = <0xd0022100 0x430>,
+	      <0xd0020800 0x20>;
+};
+
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index a564b52..f521ed8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,12 @@
 		    <0xd0021870 0x58>;
 	};
 
+	armada-370-xp-pmsu@d0022000 {
+		compatible = "marvell,armada-370-xp-pmsu";
+		reg = <0xd0022100 0x430>,
+		      <0xd0020800 0x20>;
+	};
+
 	cpus {
 	    #address-cells = <1>;
 	    #size-cells = <0>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index abd6d3b..8e6e50b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-orion/include
 
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index ea08919..74ee0b2 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -23,4 +23,5 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
 
 
 int armada_370_xp_coherency_init(void);
+int armada_370_xp_pmsu_init(void);
 #endif
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
new file mode 100644
index 0000000..cee020b
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -0,0 +1,78 @@
+/*
+ * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada 370 and Armada XP SOCs have a power management service
+ * unit which is responsible for powering down and waking up CPUs and
+ * other SOC units
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+
+static void __iomem *pmsu_mp_base;
+static void __iomem *pmsu_reset_base;
+
+#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)	((cpu * 0x100) + 0x24)
+#define PMSU_RESET_CTL_OFFSET(cpu)		(cpu * 0x8)
+
+static struct of_device_id of_pmsu_table[] = {
+	{.compatible = "marvell,armada-370-xp-pmsu"},
+	{ /* end of list */ },
+};
+
+#ifdef CONFIG_SMP
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
+{
+	int reg, hw_cpu;
+
+	if (!pmsu_mp_base || !pmsu_reset_base) {
+		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
+		return 1;
+	}
+
+	hw_cpu = cpu_logical_map(cpu_id);
+
+	writel(virt_to_phys(boot_addr), pmsu_mp_base +
+			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
+
+	/* Make sure value hits memory before reset */
+	dsb();
+
+	/* Release CPU from reset by clearing reset bit*/
+	reg = readl(pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+	reg &= (~0x1);
+	writel(reg, pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+
+	return 0;
+}
+#endif
+
+int __init armada_370_xp_pmsu_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, of_pmsu_table);
+	if (np) {
+		pr_info("Initializing Power Management Service Unit\n");
+		pmsu_mp_base = of_iomap(np, 0);
+		pmsu_reset_base = of_iomap(np, 1);
+	}
+
+	return 0;
+}
+
+early_initcall(armada_370_xp_pmsu_init);
diff --git a/arch/arm/mach-mvebu/pmsu.h b/arch/arm/mach-mvebu/pmsu.h
new file mode 100644
index 0000000..bafac8e
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.h
@@ -0,0 +1,16 @@
+/*
+ * Power Management Service Unit (PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_MVEBU_PMSU_H
+#define __MACH_MVEBU_PMSU_H
+
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *phys_addr);
+
+#endif	/* __MACH_370_XP_PMSU_H */
-- 
1.7.9.5

[PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 +++++
 arch/arm/boot/dts/armada-xp.dtsi                   |    6 ++
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/common.h                       |    1 +
 arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++++++++++
 arch/arm/mach-mvebu/pmsu.h                         |   16 ++++
 6 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
 create mode 100644 arch/arm/mach-mvebu/pmsu.c
 create mode 100644 arch/arm/mach-mvebu/pmsu.h

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
new file mode 100644
index 0000000..926b4d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
@@ -0,0 +1,20 @@
+Power Management Service Unit(PMSU)
+-----------------------------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+
+Required properties:
+
+- compatible: "marvell,armada-370-xp-pmsu"
+
+- reg: Should contain PMSU registers location and length. First pair
+  for the per-CPU SW Reset Control registers, second pair for the
+  Power Management Service Unit.
+
+Example:
+
+armada-370-xp-pmsu at d0022000 {
+	compatible = "marvell,armada-370-xp-pmsu";
+	reg = <0xd0022100 0x430>,
+	      <0xd0020800 0x20>;
+};
+
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index a564b52..f521ed8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,12 @@
 		    <0xd0021870 0x58>;
 	};
 
+	armada-370-xp-pmsu at d0022000 {
+		compatible = "marvell,armada-370-xp-pmsu";
+		reg = <0xd0022100 0x430>,
+		      <0xd0020800 0x20>;
+	};
+
 	cpus {
 	    #address-cells = <1>;
 	    #size-cells = <0>;
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index abd6d3b..8e6e50b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-orion/include
 
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index ea08919..74ee0b2 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -23,4 +23,5 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
 
 
 int armada_370_xp_coherency_init(void);
+int armada_370_xp_pmsu_init(void);
 #endif
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
new file mode 100644
index 0000000..cee020b
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -0,0 +1,78 @@
+/*
+ * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada 370 and Armada XP SOCs have a power management service
+ * unit which is responsible for powering down and waking up CPUs and
+ * other SOC units
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+
+static void __iomem *pmsu_mp_base;
+static void __iomem *pmsu_reset_base;
+
+#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)	((cpu * 0x100) + 0x24)
+#define PMSU_RESET_CTL_OFFSET(cpu)		(cpu * 0x8)
+
+static struct of_device_id of_pmsu_table[] = {
+	{.compatible = "marvell,armada-370-xp-pmsu"},
+	{ /* end of list */ },
+};
+
+#ifdef CONFIG_SMP
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
+{
+	int reg, hw_cpu;
+
+	if (!pmsu_mp_base || !pmsu_reset_base) {
+		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
+		return 1;
+	}
+
+	hw_cpu = cpu_logical_map(cpu_id);
+
+	writel(virt_to_phys(boot_addr), pmsu_mp_base +
+			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
+
+	/* Make sure value hits memory before reset */
+	dsb();
+
+	/* Release CPU from reset by clearing reset bit*/
+	reg = readl(pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+	reg &= (~0x1);
+	writel(reg, pmsu_reset_base + PMSU_RESET_CTL_OFFSET(hw_cpu));
+
+	return 0;
+}
+#endif
+
+int __init armada_370_xp_pmsu_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, of_pmsu_table);
+	if (np) {
+		pr_info("Initializing Power Management Service Unit\n");
+		pmsu_mp_base = of_iomap(np, 0);
+		pmsu_reset_base = of_iomap(np, 1);
+	}
+
+	return 0;
+}
+
+early_initcall(armada_370_xp_pmsu_init);
diff --git a/arch/arm/mach-mvebu/pmsu.h b/arch/arm/mach-mvebu/pmsu.h
new file mode 100644
index 0000000..bafac8e
--- /dev/null
+++ b/arch/arm/mach-mvebu/pmsu.h
@@ -0,0 +1,16 @@
+/*
+ * Power Management Service Unit (PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_MVEBU_PMSU_H
+#define __MACH_MVEBU_PMSU_H
+
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *phys_addr);
+
+#endif	/* __MACH_370_XP_PMSU_H */
-- 
1.7.9.5

Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Will Deacon]

On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> new file mode 100644
> index 0000000..cee020b
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -0,0 +1,78 @@
> +/*
> + * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The Armada 370 and Armada XP SOCs have a power management service
> + * unit which is responsible for powering down and waking up CPUs and
> + * other SOC units
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/smp.h>
> +#include <asm/smp_plat.h>
> +
> +static void __iomem *pmsu_mp_base;
> +static void __iomem *pmsu_reset_base;
> +
> +#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)	((cpu * 0x100) + 0x24)
> +#define PMSU_RESET_CTL_OFFSET(cpu)		(cpu * 0x8)
> +
> +static struct of_device_id of_pmsu_table[] = {
> +	{.compatible = "marvell,armada-370-xp-pmsu"},
> +	{ /* end of list */ },
> +};
> +
> +#ifdef CONFIG_SMP
> +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> +{
> +	int reg, hw_cpu;
> +
> +	if (!pmsu_mp_base || !pmsu_reset_base) {
> +		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> +		return 1;
> +	}
> +
> +	hw_cpu = cpu_logical_map(cpu_id);
> +
> +	writel(virt_to_phys(boot_addr), pmsu_mp_base +
> +			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));

virt_to_phys on an __iomem * doesn't feel right to me...

> +	/* Make sure value hits memory before reset */
> +	dsb();

writel has barrier semantics -- you shouldn't need this dsb.

Will

[PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Will Deacon]

On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> new file mode 100644
> index 0000000..cee020b
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -0,0 +1,78 @@
> +/*
> + * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The Armada 370 and Armada XP SOCs have a power management service
> + * unit which is responsible for powering down and waking up CPUs and
> + * other SOC units
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/smp.h>
> +#include <asm/smp_plat.h>
> +
> +static void __iomem *pmsu_mp_base;
> +static void __iomem *pmsu_reset_base;
> +
> +#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)	((cpu * 0x100) + 0x24)
> +#define PMSU_RESET_CTL_OFFSET(cpu)		(cpu * 0x8)
> +
> +static struct of_device_id of_pmsu_table[] = {
> +	{.compatible = "marvell,armada-370-xp-pmsu"},
> +	{ /* end of list */ },
> +};
> +
> +#ifdef CONFIG_SMP
> +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> +{
> +	int reg, hw_cpu;
> +
> +	if (!pmsu_mp_base || !pmsu_reset_base) {
> +		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> +		return 1;
> +	}
> +
> +	hw_cpu = cpu_logical_map(cpu_id);
> +
> +	writel(virt_to_phys(boot_addr), pmsu_mp_base +
> +			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));

virt_to_phys on an __iomem * doesn't feel right to me...

> +	/* Make sure value hits memory before reset */
> +	dsb();

writel has barrier semantics -- you shouldn't need this dsb.

Will

Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Russell King - ARM Linux]

On Mon, Nov 05, 2012 at 02:05:58PM +0000, Will Deacon wrote:
> On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> > +#ifdef CONFIG_SMP
> > +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> > +{
> > +	int reg, hw_cpu;
> > +
> > +	if (!pmsu_mp_base || !pmsu_reset_base) {
> > +		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> > +		return 1;
> > +	}
> > +
> > +	hw_cpu = cpu_logical_map(cpu_id);
> > +
> > +	writel(virt_to_phys(boot_addr), pmsu_mp_base +
> > +			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
> 
> virt_to_phys on an __iomem * doesn't feel right to me...

It isn't correct - I suspect the __iomem there is just wrong - and it
needs the callsite also checking.

> > +	/* Make sure value hits memory before reset */
> > +	dsb();
> 
> writel has barrier semantics -- you shouldn't need this dsb.

writel has a barrier before the write (to ensure that DMA agents see data
that was written to memory when they are enabled by the write).  There
isn't a barrier after the write.

[PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Russell King - ARM Linux]

On Mon, Nov 05, 2012 at 02:05:58PM +0000, Will Deacon wrote:
> On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> > +#ifdef CONFIG_SMP
> > +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> > +{
> > +	int reg, hw_cpu;
> > +
> > +	if (!pmsu_mp_base || !pmsu_reset_base) {
> > +		pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> > +		return 1;
> > +	}
> > +
> > +	hw_cpu = cpu_logical_map(cpu_id);
> > +
> > +	writel(virt_to_phys(boot_addr), pmsu_mp_base +
> > +			PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
> 
> virt_to_phys on an __iomem * doesn't feel right to me...

It isn't correct - I suspect the __iomem there is just wrong - and it
needs the callsite also checking.

> > +	/* Make sure value hits memory before reset */
> > +	dsb();
> 
> writel has barrier semantics -- you shouldn't need this dsb.

writel has a barrier before the write (to ensure that DMA agents see data
that was written to memory when they are enabled by the write).  There
isn't a barrier after the write.

Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Will Deacon]

On Wed, Nov 14, 2012 at 12:07:36AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 02:05:58PM +0000, Will Deacon wrote:
> > On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> > > +	/* Make sure value hits memory before reset */
> > > +	dsb();
> > 
> > writel has barrier semantics -- you shouldn't need this dsb.
> 
> writel has a barrier before the write (to ensure that DMA agents see data
> that was written to memory when they are enabled by the write).  There
> isn't a barrier after the write.

Indeed, but there's a following write to actually do the reset, so the dsb
should come from there.

Will

[PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit

[Will Deacon]

On Wed, Nov 14, 2012 at 12:07:36AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 02:05:58PM +0000, Will Deacon wrote:
> > On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> > > +	/* Make sure value hits memory before reset */
> > > +	dsb();
> > 
> > writel has barrier semantics -- you shouldn't need this dsb.
> 
> writel has a barrier before the write (to ensure that DMA agents see data
> that was written to memory when they are enabled by the write).  There
> isn't a barrier after the write.

Indeed, but there's a following write to actually do the reset, so the dsb
should come from there.

Will

[PATCH V2 3/5] arm: mvebu: Added IPI support via doorbells

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 ++-
 arch/arm/boot/dts/armada-xp.dtsi                   |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.h                |   10 +++
 arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++++++--
 4 files changed, 106 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 70c0dc5..61df564 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -6,9 +6,15 @@ Required properties:
 - interrupt-controller: Identifies the node as an interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
   The cell is the IRQ number
+
 - reg: Should contain PMIC registers location and length. First pair
   for the main interrupt registers, second pair for the per-CPU
-  interrupt registers
+  interrupt registers. For this last pair, to be compliant with SMP
+  support, the "virtual" must be use (For the record, these registers
+  automatically map to the interrupt controller registers of the
+  current CPU)
+
+
 
 Example:
 
@@ -18,6 +24,6 @@ Example:
               #address-cells = <1>;
               #size-cells = <1>;
               interrupt-controller;
-              reg = <0xd0020000 0x1000>,
-                    <0xd0021000 0x1000>;
+              reg = <0xd0020a00 0x1d0>,
+                    <0xd0021070 0x58>;
         };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index f521ed8..531619f 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -24,7 +24,7 @@
 
 	mpic: interrupt-controller@d0020000 {
 	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
+		    <0xd0021070 0x58>;
 	};
 
 	armada-370-xp-pmsu@d0022000 {
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h
index aac9beb..dce590d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -19,4 +19,14 @@
 #define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfeb00000)
 #define ARMADA_370_XP_REGS_SIZE		SZ_1M
 
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_SMP
+#include <linux/cpumask.h>
+
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq);
+void armada_xp_mpic_smp_cpu_init(void);
+#endif
+#endif
+
 #endif /* __MACH_ARMADA_370_XP_H */
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 5f5f939..549b684 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -24,6 +24,7 @@
 #include <linux/irqdomain.h>
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
+#include <asm/smp_plat.h>
 
 /* Interrupt Controller Registers Map */
 #define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
@@ -35,6 +36,12 @@
 
 #define ARMADA_370_XP_CPU_INTACK_OFFS		(0x44)
 
+#define ARMADA_370_XP_SW_TRIG_INT_OFFS           (0x4)
+#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS          (0xc)
+#define ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS        (0x8)
+
+#define ACTIVE_DOORBELLS			(8)
+
 static void __iomem *per_cpu_int_base;
 static void __iomem *main_int_base;
 static struct irq_domain *armada_370_xp_mpic_domain;
@@ -51,11 +58,22 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 	       per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
+#ifdef CONFIG_SMP
+static int armada_xp_set_affinity(struct irq_data *d,
+				  const struct cpumask *mask_val, bool force)
+{
+	return 0;
+}
+#endif
+
 static struct irq_chip armada_370_xp_irq_chip = {
 	.name		= "armada_370_xp_irq",
 	.irq_mask       = armada_370_xp_irq_mask,
 	.irq_mask_ack   = armada_370_xp_irq_mask,
 	.irq_unmask     = armada_370_xp_irq_unmask,
+#ifdef CONFIG_SMP
+	.irq_set_affinity = armada_xp_set_affinity,
+#endif
 };
 
 static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
@@ -72,6 +90,41 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 	return 0;
 }
 
+#ifdef CONFIG_SMP
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq)
+{
+	int cpu;
+	unsigned long map = 0;
+
+	/* Convert our logical CPU mask into a physical one. */
+	for_each_cpu(cpu, mask)
+		map |= 1 << cpu_logical_map(cpu);
+
+	/*
+	 * Ensure that stores to Normal memory are visible to the
+	 * other CPUs before issuing the IPI.
+	 */
+	dsb();
+
+	/* submit softirq */
+	writel((map << 8) | irq, main_int_base +
+		ARMADA_370_XP_SW_TRIG_INT_OFFS);
+}
+
+void armada_xp_mpic_smp_cpu_init(void)
+{
+	/* Clear pending IPIs */
+	writel(0, per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+	/* Enable first 8 IPIs */
+	writel((1 << ACTIVE_DOORBELLS) - 1, per_cpu_int_base +
+		ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+	/* Unmask IPI interrupt */
+	writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+#endif /* CONFIG_SMP */
+
 static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 	.map = armada_370_xp_mpic_irq_map,
 	.xlate = irq_domain_xlate_onecell,
@@ -91,13 +144,18 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
 
 	armada_370_xp_mpic_domain =
-	    irq_domain_add_linear(node, (control >> 2) & 0x3ff,
-				  &armada_370_xp_mpic_irq_ops, NULL);
+		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
+				&armada_370_xp_mpic_irq_ops, NULL);
 
 	if (!armada_370_xp_mpic_domain)
 		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
 
 	irq_set_default_host(armada_370_xp_mpic_domain);
+
+#ifdef CONFIG_SMP
+	armada_xp_mpic_smp_cpu_init();
+#endif
+
 	return 0;
 }
 
@@ -111,14 +169,36 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
 					ARMADA_370_XP_CPU_INTACK_OFFS);
 		irqnr = irqstat & 0x3FF;
 
-		if (irqnr < 1023) {
-			irqnr =
-			    irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
+		if (irqnr > 1022)
+			break;
+
+		if (irqnr >= 8) {
+			irqnr =	irq_find_mapping(armada_370_xp_mpic_domain,
+					irqnr);
 			handle_IRQ(irqnr, regs);
 			continue;
 		}
+#ifdef CONFIG_SMP
+		/* IPI Handling */
+		if (irqnr == 0) {
+			u32 ipimask, ipinr;
+
+			ipimask = readl_relaxed(per_cpu_int_base +
+						ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+				& 0xFF;
+
+			writel(0x0, per_cpu_int_base +
+				ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+			/* Handle all pending doorbells */
+			for (ipinr = 0; ipinr < ACTIVE_DOORBELLS; ipinr++) {
+				if (ipimask & (0x1 << ipinr))
+					handle_IPI(ipinr, regs);
+			}
+			continue;
+		}
+#endif
 
-		break;
 	} while (1);
 }
 
-- 
1.7.9.5

[PATCH V2 3/5] arm: mvebu: Added IPI support via doorbells

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 ++-
 arch/arm/boot/dts/armada-xp.dtsi                   |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.h                |   10 +++
 arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++++++--
 4 files changed, 106 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 70c0dc5..61df564 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -6,9 +6,15 @@ Required properties:
 - interrupt-controller: Identifies the node as an interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
   The cell is the IRQ number
+
 - reg: Should contain PMIC registers location and length. First pair
   for the main interrupt registers, second pair for the per-CPU
-  interrupt registers
+  interrupt registers. For this last pair, to be compliant with SMP
+  support, the "virtual" must be use (For the record, these registers
+  automatically map to the interrupt controller registers of the
+  current CPU)
+
+
 
 Example:
 
@@ -18,6 +24,6 @@ Example:
               #address-cells = <1>;
               #size-cells = <1>;
               interrupt-controller;
-              reg = <0xd0020000 0x1000>,
-                    <0xd0021000 0x1000>;
+              reg = <0xd0020a00 0x1d0>,
+                    <0xd0021070 0x58>;
         };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index f521ed8..531619f 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -24,7 +24,7 @@
 
 	mpic: interrupt-controller at d0020000 {
 	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
+		    <0xd0021070 0x58>;
 	};
 
 	armada-370-xp-pmsu at d0022000 {
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h
index aac9beb..dce590d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -19,4 +19,14 @@
 #define ARMADA_370_XP_REGS_VIRT_BASE	IOMEM(0xfeb00000)
 #define ARMADA_370_XP_REGS_SIZE		SZ_1M
 
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_SMP
+#include <linux/cpumask.h>
+
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq);
+void armada_xp_mpic_smp_cpu_init(void);
+#endif
+#endif
+
 #endif /* __MACH_ARMADA_370_XP_H */
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 5f5f939..549b684 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -24,6 +24,7 @@
 #include <linux/irqdomain.h>
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
+#include <asm/smp_plat.h>
 
 /* Interrupt Controller Registers Map */
 #define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
@@ -35,6 +36,12 @@
 
 #define ARMADA_370_XP_CPU_INTACK_OFFS		(0x44)
 
+#define ARMADA_370_XP_SW_TRIG_INT_OFFS           (0x4)
+#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS          (0xc)
+#define ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS        (0x8)
+
+#define ACTIVE_DOORBELLS			(8)
+
 static void __iomem *per_cpu_int_base;
 static void __iomem *main_int_base;
 static struct irq_domain *armada_370_xp_mpic_domain;
@@ -51,11 +58,22 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 	       per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
+#ifdef CONFIG_SMP
+static int armada_xp_set_affinity(struct irq_data *d,
+				  const struct cpumask *mask_val, bool force)
+{
+	return 0;
+}
+#endif
+
 static struct irq_chip armada_370_xp_irq_chip = {
 	.name		= "armada_370_xp_irq",
 	.irq_mask       = armada_370_xp_irq_mask,
 	.irq_mask_ack   = armada_370_xp_irq_mask,
 	.irq_unmask     = armada_370_xp_irq_unmask,
+#ifdef CONFIG_SMP
+	.irq_set_affinity = armada_xp_set_affinity,
+#endif
 };
 
 static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
@@ -72,6 +90,41 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
 	return 0;
 }
 
+#ifdef CONFIG_SMP
+void armada_mpic_send_doorbell(const struct cpumask *mask, unsigned int irq)
+{
+	int cpu;
+	unsigned long map = 0;
+
+	/* Convert our logical CPU mask into a physical one. */
+	for_each_cpu(cpu, mask)
+		map |= 1 << cpu_logical_map(cpu);
+
+	/*
+	 * Ensure that stores to Normal memory are visible to the
+	 * other CPUs before issuing the IPI.
+	 */
+	dsb();
+
+	/* submit softirq */
+	writel((map << 8) | irq, main_int_base +
+		ARMADA_370_XP_SW_TRIG_INT_OFFS);
+}
+
+void armada_xp_mpic_smp_cpu_init(void)
+{
+	/* Clear pending IPIs */
+	writel(0, per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+	/* Enable first 8 IPIs */
+	writel((1 << ACTIVE_DOORBELLS) - 1, per_cpu_int_base +
+		ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+	/* Unmask IPI interrupt */
+	writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+#endif /* CONFIG_SMP */
+
 static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 	.map = armada_370_xp_mpic_irq_map,
 	.xlate = irq_domain_xlate_onecell,
@@ -91,13 +144,18 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
 
 	armada_370_xp_mpic_domain =
-	    irq_domain_add_linear(node, (control >> 2) & 0x3ff,
-				  &armada_370_xp_mpic_irq_ops, NULL);
+		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
+				&armada_370_xp_mpic_irq_ops, NULL);
 
 	if (!armada_370_xp_mpic_domain)
 		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
 
 	irq_set_default_host(armada_370_xp_mpic_domain);
+
+#ifdef CONFIG_SMP
+	armada_xp_mpic_smp_cpu_init();
+#endif
+
 	return 0;
 }
 
@@ -111,14 +169,36 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
 					ARMADA_370_XP_CPU_INTACK_OFFS);
 		irqnr = irqstat & 0x3FF;
 
-		if (irqnr < 1023) {
-			irqnr =
-			    irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
+		if (irqnr > 1022)
+			break;
+
+		if (irqnr >= 8) {
+			irqnr =	irq_find_mapping(armada_370_xp_mpic_domain,
+					irqnr);
 			handle_IRQ(irqnr, regs);
 			continue;
 		}
+#ifdef CONFIG_SMP
+		/* IPI Handling */
+		if (irqnr == 0) {
+			u32 ipimask, ipinr;
+
+			ipimask = readl_relaxed(per_cpu_int_base +
+						ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+				& 0xFF;
+
+			writel(0x0, per_cpu_int_base +
+				ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+			/* Handle all pending doorbells */
+			for (ipinr = 0; ipinr < ACTIVE_DOORBELLS; ipinr++) {
+				if (ipimask & (0x1 << ipinr))
+					handle_IPI(ipinr, regs);
+			}
+			continue;
+		}
+#endif
 
-		break;
 	} while (1);
 }
 
-- 
1.7.9.5

[PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig |    2 +-
 arch/arm/mm/Kconfig         |    4 ++++
 arch/arm/mm/proc-v7.S       |   43 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 17d246b..9bfaa0c 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,7 +22,7 @@ config MVEBU_CLK_CPU
 config MACH_ARMADA_370_XP
 	bool
 	select ARMADA_370_XP_TIMER
-	select CPU_V7
+	select CPU_PJ4B
 
 config MACH_ARMADA_370
 	bool "Marvell Armada 370 boards"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 94186b6..3fd629d 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -352,6 +352,10 @@ config CPU_PJ4
 	select ARM_THUMBEE
 	select CPU_V7
 
+config CPU_PJ4B
+	bool
+	select CPU_V7
+
 # ARMv6
 config CPU_V6
 	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 846d279..1a373c2 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -169,6 +169,39 @@ __v7_ca15mp_setup:
 	orreq	r0, r0, r10			@ Enable CPU-specific SMP bits
 	mcreq	p15, 0, r0, c1, c0, 1
 #endif
+
+__v7_pj4b_setup:
+#ifdef CONFIG_CPU_PJ4B
+	/* Auxiliary Debug Modes Control 1 Register */
+	mrc	p15, 1,	r0, c15, c1, 1
+	orr	r0, r0, #(1 << 16)     @ Disable data transfer for clean line.
+	orr	r0, r0, #(1 << 5)      @ Enable the back off of STREX instr
+	orr	r0, r0, #(1 << 8)      @ Disable Internal Parity Handling
+	bic	r0, r0, #(1 << 2)      @ Disable Static BP
+	mcr	p15, 1,	r0, c15, c1, 1
+
+	/* Auxiliary Debug Modes Control 2 Register */
+	mrc	p15, 1,	r0, c15, c1, 2
+	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
+	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
+	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
+	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
+	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin
+	mcr	p15, 1,	r0, c15, c1, 2
+
+	/* Auxiliary Functional Modes Control Register 0 */
+	mrc	p15, 1,	r0, c15, c2, 0
+	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
+	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
+	mcr	p15, 1,	r0, c15, c2, 0
+
+	/* Auxiliary Debug Modes Control 0 Register */
+	mrc	p15, 1,	r0, c15, c1, 0
+	orr	r0, r0, #(1 << 22)   @ WFI/WFE - serve the DVM and back to idle
+	mcr	p15, 1,	r0, c15, c1, 0
+
+#endif /* CONFIG_CPU_PJ4B */
+
 __v7_setup:
 	adr	r12, __v7_setup_stack		@ the local stack
 	stmia	r12, {r0-r5, r7, r9, r11, lr}
@@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
 	.long	0xff0ffff0
 	__v7_proc __v7_ca9mp_setup
 	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
+
+	/*
+	 * Marvell PJ4B processor.
+	 */
+	.type   __v7_pj4b_proc_info, #object
+__v7_pj4b_proc_info:
+	.long	0x562f5842
+	.long	0xffffffff
+	__v7_proc __v7_pj4b_setup
+	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
 #endif	/* CONFIG_ARM_LPAE */
 
 	/*
-- 
1.7.9.5

[PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig |    2 +-
 arch/arm/mm/Kconfig         |    4 ++++
 arch/arm/mm/proc-v7.S       |   43 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 17d246b..9bfaa0c 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,7 +22,7 @@ config MVEBU_CLK_CPU
 config MACH_ARMADA_370_XP
 	bool
 	select ARMADA_370_XP_TIMER
-	select CPU_V7
+	select CPU_PJ4B
 
 config MACH_ARMADA_370
 	bool "Marvell Armada 370 boards"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 94186b6..3fd629d 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -352,6 +352,10 @@ config CPU_PJ4
 	select ARM_THUMBEE
 	select CPU_V7
 
+config CPU_PJ4B
+	bool
+	select CPU_V7
+
 # ARMv6
 config CPU_V6
 	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 846d279..1a373c2 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -169,6 +169,39 @@ __v7_ca15mp_setup:
 	orreq	r0, r0, r10			@ Enable CPU-specific SMP bits
 	mcreq	p15, 0, r0, c1, c0, 1
 #endif
+
+__v7_pj4b_setup:
+#ifdef CONFIG_CPU_PJ4B
+	/* Auxiliary Debug Modes Control 1 Register */
+	mrc	p15, 1,	r0, c15, c1, 1
+	orr	r0, r0, #(1 << 16)     @ Disable data transfer for clean line.
+	orr	r0, r0, #(1 << 5)      @ Enable the back off of STREX instr
+	orr	r0, r0, #(1 << 8)      @ Disable Internal Parity Handling
+	bic	r0, r0, #(1 << 2)      @ Disable Static BP
+	mcr	p15, 1,	r0, c15, c1, 1
+
+	/* Auxiliary Debug Modes Control 2 Register */
+	mrc	p15, 1,	r0, c15, c1, 2
+	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
+	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
+	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
+	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
+	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin
+	mcr	p15, 1,	r0, c15, c1, 2
+
+	/* Auxiliary Functional Modes Control Register 0 */
+	mrc	p15, 1,	r0, c15, c2, 0
+	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
+	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
+	mcr	p15, 1,	r0, c15, c2, 0
+
+	/* Auxiliary Debug Modes Control 0 Register */
+	mrc	p15, 1,	r0, c15, c1, 0
+	orr	r0, r0, #(1 << 22)   @ WFI/WFE - serve the DVM and back to idle
+	mcr	p15, 1,	r0, c15, c1, 0
+
+#endif /* CONFIG_CPU_PJ4B */
+
 __v7_setup:
 	adr	r12, __v7_setup_stack		@ the local stack
 	stmia	r12, {r0-r5, r7, r9, r11, lr}
@@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
 	.long	0xff0ffff0
 	__v7_proc __v7_ca9mp_setup
 	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
+
+	/*
+	 * Marvell PJ4B processor.
+	 */
+	.type   __v7_pj4b_proc_info, #object
+__v7_pj4b_proc_info:
+	.long	0x562f5842
+	.long	0xffffffff
+	__v7_proc __v7_pj4b_setup
+	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
 #endif	/* CONFIG_ARM_LPAE */
 
 	/*
-- 
1.7.9.5

Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Gregory CLEMENT]

Russell,

Do you have any comments on this patch?
Else do you agree to give your acked-by?

Thanks,

Gregory


On 10/29/2012 10:11 PM, Gregory CLEMENT wrote:
> From: Yehuda Yitschak <yehuday@marvell.com>
> 
> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  arch/arm/mach-mvebu/Kconfig |    2 +-
>  arch/arm/mm/Kconfig         |    4 ++++
>  arch/arm/mm/proc-v7.S       |   43 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 17d246b..9bfaa0c 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -22,7 +22,7 @@ config MVEBU_CLK_CPU
>  config MACH_ARMADA_370_XP
>  	bool
>  	select ARMADA_370_XP_TIMER
> -	select CPU_V7
> +	select CPU_PJ4B
>  
>  config MACH_ARMADA_370
>  	bool "Marvell Armada 370 boards"
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 94186b6..3fd629d 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -352,6 +352,10 @@ config CPU_PJ4
>  	select ARM_THUMBEE
>  	select CPU_V7
>  
> +config CPU_PJ4B
> +	bool
> +	select CPU_V7
> +
>  # ARMv6
>  config CPU_V6
>  	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 846d279..1a373c2 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -169,6 +169,39 @@ __v7_ca15mp_setup:
>  	orreq	r0, r0, r10			@ Enable CPU-specific SMP bits
>  	mcreq	p15, 0, r0, c1, c0, 1
>  #endif
> +
> +__v7_pj4b_setup:
> +#ifdef CONFIG_CPU_PJ4B
> +	/* Auxiliary Debug Modes Control 1 Register */
> +	mrc	p15, 1,	r0, c15, c1, 1
> +	orr	r0, r0, #(1 << 16)     @ Disable data transfer for clean line.
> +	orr	r0, r0, #(1 << 5)      @ Enable the back off of STREX instr
> +	orr	r0, r0, #(1 << 8)      @ Disable Internal Parity Handling
> +	bic	r0, r0, #(1 << 2)      @ Disable Static BP
> +	mcr	p15, 1,	r0, c15, c1, 1
> +
> +	/* Auxiliary Debug Modes Control 2 Register */
> +	mrc	p15, 1,	r0, c15, c1, 2
> +	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
> +	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
> +	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
> +	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
> +	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin
> +	mcr	p15, 1,	r0, c15, c1, 2
> +
> +	/* Auxiliary Functional Modes Control Register 0 */
> +	mrc	p15, 1,	r0, c15, c2, 0
> +	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
> +	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
> +	mcr	p15, 1,	r0, c15, c2, 0
> +
> +	/* Auxiliary Debug Modes Control 0 Register */
> +	mrc	p15, 1,	r0, c15, c1, 0
> +	orr	r0, r0, #(1 << 22)   @ WFI/WFE - serve the DVM and back to idle
> +	mcr	p15, 1,	r0, c15, c1, 0
> +
> +#endif /* CONFIG_CPU_PJ4B */
> +
>  __v7_setup:
>  	adr	r12, __v7_setup_stack		@ the local stack
>  	stmia	r12, {r0-r5, r7, r9, r11, lr}
> @@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
>  	.long	0xff0ffff0
>  	__v7_proc __v7_ca9mp_setup
>  	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
> +
> +	/*
> +	 * Marvell PJ4B processor.
> +	 */
> +	.type   __v7_pj4b_proc_info, #object
> +__v7_pj4b_proc_info:
> +	.long	0x562f5842
> +	.long	0xffffffff
> +	__v7_proc __v7_pj4b_setup
> +	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
>  #endif	/* CONFIG_ARM_LPAE */
>  
>  	/*
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Gregory CLEMENT]

Russell,

Do you have any comments on this patch?
Else do you agree to give your acked-by?

Thanks,

Gregory


On 10/29/2012 10:11 PM, Gregory CLEMENT wrote:
> From: Yehuda Yitschak <yehuday@marvell.com>
> 
> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  arch/arm/mach-mvebu/Kconfig |    2 +-
>  arch/arm/mm/Kconfig         |    4 ++++
>  arch/arm/mm/proc-v7.S       |   43 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 17d246b..9bfaa0c 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -22,7 +22,7 @@ config MVEBU_CLK_CPU
>  config MACH_ARMADA_370_XP
>  	bool
>  	select ARMADA_370_XP_TIMER
> -	select CPU_V7
> +	select CPU_PJ4B
>  
>  config MACH_ARMADA_370
>  	bool "Marvell Armada 370 boards"
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 94186b6..3fd629d 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -352,6 +352,10 @@ config CPU_PJ4
>  	select ARM_THUMBEE
>  	select CPU_V7
>  
> +config CPU_PJ4B
> +	bool
> +	select CPU_V7
> +
>  # ARMv6
>  config CPU_V6
>  	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 846d279..1a373c2 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -169,6 +169,39 @@ __v7_ca15mp_setup:
>  	orreq	r0, r0, r10			@ Enable CPU-specific SMP bits
>  	mcreq	p15, 0, r0, c1, c0, 1
>  #endif
> +
> +__v7_pj4b_setup:
> +#ifdef CONFIG_CPU_PJ4B
> +	/* Auxiliary Debug Modes Control 1 Register */
> +	mrc	p15, 1,	r0, c15, c1, 1
> +	orr	r0, r0, #(1 << 16)     @ Disable data transfer for clean line.
> +	orr	r0, r0, #(1 << 5)      @ Enable the back off of STREX instr
> +	orr	r0, r0, #(1 << 8)      @ Disable Internal Parity Handling
> +	bic	r0, r0, #(1 << 2)      @ Disable Static BP
> +	mcr	p15, 1,	r0, c15, c1, 1
> +
> +	/* Auxiliary Debug Modes Control 2 Register */
> +	mrc	p15, 1,	r0, c15, c1, 2
> +	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
> +	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
> +	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
> +	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
> +	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin
> +	mcr	p15, 1,	r0, c15, c1, 2
> +
> +	/* Auxiliary Functional Modes Control Register 0 */
> +	mrc	p15, 1,	r0, c15, c2, 0
> +	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
> +	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
> +	mcr	p15, 1,	r0, c15, c2, 0
> +
> +	/* Auxiliary Debug Modes Control 0 Register */
> +	mrc	p15, 1,	r0, c15, c1, 0
> +	orr	r0, r0, #(1 << 22)   @ WFI/WFE - serve the DVM and back to idle
> +	mcr	p15, 1,	r0, c15, c1, 0
> +
> +#endif /* CONFIG_CPU_PJ4B */
> +
>  __v7_setup:
>  	adr	r12, __v7_setup_stack		@ the local stack
>  	stmia	r12, {r0-r5, r7, r9, r11, lr}
> @@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
>  	.long	0xff0ffff0
>  	__v7_proc __v7_ca9mp_setup
>  	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
> +
> +	/*
> +	 * Marvell PJ4B processor.
> +	 */
> +	.type   __v7_pj4b_proc_info, #object
> +__v7_pj4b_proc_info:
> +	.long	0x562f5842
> +	.long	0xffffffff
> +	__v7_proc __v7_pj4b_setup
> +	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
>  #endif	/* CONFIG_ARM_LPAE */
>  
>  	/*
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Will Deacon]

On Tue, Nov 13, 2012 at 03:15:16PM +0000, Gregory CLEMENT wrote:
> >  __v7_setup:
> >  	adr	r12, __v7_setup_stack		@ the local stack
> >  	stmia	r12, {r0-r5, r7, r9, r11, lr}
> > @@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
> >  	.long	0xff0ffff0
> >  	__v7_proc __v7_ca9mp_setup
> >  	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
> > +
> > +	/*
> > +	 * Marvell PJ4B processor.
> > +	 */
> > +	.type   __v7_pj4b_proc_info, #object
> > +__v7_pj4b_proc_info:
> > +	.long	0x562f5842
> > +	.long	0xffffffff

This mask seems a little excessive -- does your cpuid not contain revision
information? If so, I'm not sure we want to update the code every time there
is a new spin of the same CPU.

Will

[PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Will Deacon]

On Tue, Nov 13, 2012 at 03:15:16PM +0000, Gregory CLEMENT wrote:
> >  __v7_setup:
> >  	adr	r12, __v7_setup_stack		@ the local stack
> >  	stmia	r12, {r0-r5, r7, r9, r11, lr}
> > @@ -342,6 +375,16 @@ __v7_ca9mp_proc_info:
> >  	.long	0xff0ffff0
> >  	__v7_proc __v7_ca9mp_setup
> >  	.size	__v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
> > +
> > +	/*
> > +	 * Marvell PJ4B processor.
> > +	 */
> > +	.type   __v7_pj4b_proc_info, #object
> > +__v7_pj4b_proc_info:
> > +	.long	0x562f5842
> > +	.long	0xffffffff

This mask seems a little excessive -- does your cpuid not contain revision
information? If so, I'm not sure we want to update the code every time there
is a new spin of the same CPU.

Will

Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Russell King - ARM Linux]

On Mon, Oct 29, 2012 at 10:11:47PM +0100, Gregory CLEMENT wrote:
> +	/* Auxiliary Debug Modes Control 2 Register */
> +	mrc	p15, 1,	r0, c15, c1, 2
> +	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
> +	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
> +	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
> +	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
> +	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin

This just looks silly to me - setting five bits with five instructions
when they can all be done in one instruction.  Yes, I know you want
to comment it, but there's other ways to achieve that.

> +__v7_pj4b_proc_info:
> +	.long	0x562f5842
> +	.long	0xffffffff

Same comment here as Will :)

[PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines

[Russell King - ARM Linux]

On Mon, Oct 29, 2012 at 10:11:47PM +0100, Gregory CLEMENT wrote:
> +	/* Auxiliary Debug Modes Control 2 Register */
> +	mrc	p15, 1,	r0, c15, c1, 2
> +	bic	r0, r0, #(1 << 23)   @ Enable fast LDR.
> +	orr	r0, r0, #(1 << 25)   @ Dont interleave write and snoop data.
> +	orr	r0, r0, #(1 << 27)   @ Disable Critical Word First feature.
> +	orr	r0, r0, #(1 << 29)   @ Disable outstanding non cacheable request
> +	orr	r0, r0, #(1 << 30)   @ L1 replacement - Strict round robin

This just looks silly to me - setting five bits with five instructions
when they can all be done in one instruction.  Yes, I know you want
to comment it, but there's other ways to achieve that.

> +__v7_pj4b_proc_info:
> +	.long	0x562f5842
> +	.long	0xffffffff

Same comment here as Will :)

[PATCH V2 5/5] arm: mvebu: Added SMP support for Armada XP

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

1. added smp init functions in platsmp.c
2. added secondary cpu entry point in headsmp.S
3. added hotplog initial support in hotplug.c
4. added SMP support for PJ4B cpu

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp.dtsi    |    4 ++
 arch/arm/configs/mvebu_defconfig    |    3 +
 arch/arm/mach-mvebu/Kconfig         |    1 +
 arch/arm/mach-mvebu/Makefile        |    2 +
 arch/arm/mach-mvebu/armada-370-xp.c |    3 +
 arch/arm/mach-mvebu/common.h        |    3 +
 arch/arm/mach-mvebu/headsmp.S       |   66 +++++++++++++++++++
 arch/arm/mach-mvebu/hotplug.c       |   30 +++++++++
 arch/arm/mach-mvebu/platsmp.c       |  124 +++++++++++++++++++++++++++++++++++
 arch/arm/mm/proc-v7.S               |    3 +
 10 files changed, 239 insertions(+)
 create mode 100644 arch/arm/mach-mvebu/headsmp.S
 create mode 100644 arch/arm/mach-mvebu/hotplug.c
 create mode 100644 arch/arm/mach-mvebu/platsmp.c

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 531619f..7f968dc 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -38,24 +38,28 @@
 	    #size-cells = <0>;
 
 	    cpu@0 {
+		device_type = "cpu";
 	       	compatible = "marvell,sheeva-v7";
 		reg = <0>;
 		clocks = <&cpuclk 0>;
 	    };
 
 	    cpu@1 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <1>;
 		clocks = <&cpuclk 1>;
 	    };
 
 	    cpu@2 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <2>;
 		clocks = <&cpuclk 2>;
 	    };
 
 	    cpu@3 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <3>;
 		clocks = <&cpuclk 3>;
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 3458752..da598d3 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -12,6 +12,9 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 # CONFIG_CACHE_L2X0 is not set
+# CONFIG_SWP_EMULATE is not set
+CONFIG_SMP=y
+# CONFIG_LOCAL_TIMERS is not set
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 # CONFIG_COMPACTION is not set
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 9bfaa0c..d70afe3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,6 +22,7 @@ config MVEBU_CLK_CPU
 config MACH_ARMADA_370_XP
 	bool
 	select ARMADA_370_XP_TIMER
+	select HAVE_SMP
 	select CPU_PJ4B
 
 config MACH_ARMADA_370
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 8e6e50b..eb3cbd1 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -3,3 +3,5 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 
 obj-y += system-controller.o
 obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
+obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
+obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..66befa1 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -22,6 +22,7 @@
 #include <asm/mach/time.h>
 #include "armada-370-xp.h"
 #include "common.h"
+#include "coherency.h"
 
 static struct map_desc armada_370_xp_io_desc[] __initdata = {
 	{
@@ -50,6 +51,7 @@ struct sys_timer armada_370_xp_timer = {
 static void __init armada_370_xp_dt_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	coherency_init();
 }
 
 static const char * const armada_370_xp_dt_board_dt_compat[] = {
@@ -59,6 +61,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
 };
 
 DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
+	.smp		= smp_ops(armada_xp_smp_ops),
 	.init_machine	= armada_370_xp_dt_init,
 	.map_io		= armada_370_xp_map_io,
 	.init_irq	= armada_370_xp_init_irq,
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 74ee0b2..86484bb 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,7 +21,10 @@ void mvebu_clocks_init(void);
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
 
+void armada_xp_cpu_die(unsigned int cpu);
 
 int armada_370_xp_coherency_init(void);
 int armada_370_xp_pmsu_init(void);
+void armada_xp_secondary_startup(void);
+extern struct smp_operations armada_xp_smp_ops;
 #endif
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
new file mode 100644
index 0000000..33db1d5
--- /dev/null
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -0,0 +1,66 @@
+/*
+ * SMP support: Entry point for secondary CPUs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This file implements the assembly entry point for secondary CPUs
+ * in an SMP kernel. The only thing we need to do is to add the CPU
+ * to the coherency fabric by writing to 2 registers. Currently these
+ * register addresses are hard coded due to the early initialisation problems.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+/*
+ * At this stage the secondary CPUs don't have acces yet to the MMU, so
+ * we have to provide physical addresses
+ */
+#define ARMADA_XP_COHERENCY_FABRIC_CTL_REG 0xD0020200
+#define ARMADA_XP_COHERENCY_FABRIC_CFG_REG 0xD0020204
+
+	__INIT
+
+/*
+ * Armada XP specific entry point for secondary CPUs.
+ * We add the CPU to the coherency fabric and then jump to secondary
+ * startup
+ */
+
+ENTRY(armada_xp_secondary_startup)
+
+	/* Read CPU id */
+ 	mrc     p15, 0, r1, c0, c0, 5
+	and     r1, r1, #0xF
+
+	/* Add CPU to coherency fabric */
+
+	/* Create bit by cpu index */
+	mov     r2,r1
+	add     r2,r2,#24
+	mov     r3, #1
+	lsl     r3, r3, r2
+
+	/* Add CPU to SMP group - Atomic */
+	ldr     r0, = ARMADA_XP_COHERENCY_FABRIC_CTL_REG
+	ldr     r10, [r0]
+	orr     r10 , r10, r3
+	str	r10,[r0]
+
+	/* Enable coherency on CPU - Atomic*/
+	ldr     r0, = ARMADA_XP_COHERENCY_FABRIC_CFG_REG
+	ldr     r10, [r0]
+	orr     r10 , r10, r3
+	str     r10,[r0]
+
+	b	secondary_startup
+
+ENDPROC(armada_xp_secondary_startup)
diff --git a/arch/arm/mach-mvebu/hotplug.c b/arch/arm/mach-mvebu/hotplug.c
new file mode 100644
index 0000000..b228b6a
--- /dev/null
+++ b/arch/arm/mach-mvebu/hotplug.c
@@ -0,0 +1,30 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/smp.h>
+#include <asm/proc-fns.h>
+
+/*
+ * platform-specific code to shutdown a CPU
+ *
+ * Called with IRQs disabled
+ */
+void __ref armada_xp_cpu_die(unsigned int cpu)
+{
+	cpu_do_idle();
+
+	/* We should never return from idle */
+	panic("mvebu: cpu %d unexpectedly exit from shutdown\n", cpu);
+}
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
new file mode 100644
index 0000000..1cd6c08
--- /dev/null
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -0,0 +1,124 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada XP SoC has 4 ARMv7 PJ4B CPUs running in full HW coherency
+ * This file implements the routines for preparing the SMP infrastructure
+ * and waking up the secondary CPUs
+ */
+
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_plat.h>
+#include "common.h"
+#include "armada-370-xp.h"
+#include "pmsu.h"
+#include "coherency.h"
+
+void __init set_secondary_cpus_clock(void)
+{
+	int cpu;
+	unsigned long rate;
+	struct clk *cpu_clk = NULL;
+	struct device_node *np = NULL;
+
+	cpu = smp_processor_id();
+	np = of_find_node_by_type(np, "cpu");
+	np = NULL;
+	while ((np = of_find_node_by_type(np, "cpu"))) {
+		const u32 *reg;
+		int len;
+		reg = of_get_property(np, "reg", &len);
+		if (!reg || len != 4) {
+			pr_err("%s missing reg property\n", np->full_name);
+			continue;
+		}
+		if (be32_to_cpup(reg) == cpu) {
+			cpu_clk = of_clk_get(np, 0);
+			break;
+		}
+	}
+	WARN_ON(IS_ERR(cpu_clk));
+	clk_prepare_enable(cpu_clk);
+	rate = clk_get_rate(cpu_clk);
+
+	/* set all the other CPU clk to the same rate than the boot CPU */
+	np = NULL;
+	while ((np = of_find_node_by_type(np, "cpu"))) {
+		const u32 *reg;
+		int len;
+		reg = of_get_property(np, "reg", &len);
+		if (!reg || len != 4) {
+			pr_err("%s missing reg property\n", np->full_name);
+			continue;
+		}
+		if (be32_to_cpup(reg) != cpu) {
+			cpu_clk = of_clk_get(np, 0);
+			clk_set_rate(cpu_clk, rate);
+		}
+	}
+}
+
+static void __cpuinit armada_xp_secondary_init(unsigned int cpu)
+{
+	armada_xp_mpic_smp_cpu_init();
+}
+
+static int __cpuinit armada_xp_boot_secondary(unsigned int cpu,
+					      struct task_struct *idle)
+{
+	pr_info("Booting CPU %d\n", cpu);
+
+	armada_xp_boot_cpu(cpu, armada_xp_secondary_startup);
+
+	return 0;
+}
+
+static void __init armada_xp_smp_init_cpus(void)
+{
+	unsigned int i, ncores;
+	ncores = coherency_get_cpu_count();
+
+	/* Limit possbile CPUs to defconfig */
+	if (ncores > nr_cpu_ids) {
+		pr_warn("SMP: %d CPUs physically present. Only %d configured.",
+			ncores, nr_cpu_ids);
+		pr_warn("Clipping CPU count to %d\n", nr_cpu_ids);
+		ncores = nr_cpu_ids;
+	}
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+
+	set_smp_cross_call(armada_mpic_send_doorbell);
+}
+
+void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
+{
+	set_secondary_cpus_clock();
+	flush_cache_all();
+	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+}
+
+struct smp_operations armada_xp_smp_ops __initdata = {
+	.smp_init_cpus		= armada_xp_smp_init_cpus,
+	.smp_prepare_cpus	= armada_xp_smp_prepare_cpus,
+	.smp_secondary_init	= armada_xp_secondary_init,
+	.smp_boot_secondary	= armada_xp_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_die		= armada_xp_cpu_die,
+#endif
+};
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 1a373c2..dcd97e4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -191,6 +191,9 @@ __v7_pj4b_setup:
 
 	/* Auxiliary Functional Modes Control Register 0 */
 	mrc	p15, 1,	r0, c15, c2, 0
+#ifdef CONFIG_SMP
+	orr	r0, r0, #(1 << 1)     @ Set SMP mode. Join the coherency fabric
+#endif
 	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
 	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
 	mcr	p15, 1,	r0, c15, c2, 0
-- 
1.7.9.5

[PATCH V2 5/5] arm: mvebu: Added SMP support for Armada XP

[Gregory CLEMENT]

From: Yehuda Yitschak <yehuday@marvell.com>

1. added smp init functions in platsmp.c
2. added secondary cpu entry point in headsmp.S
3. added hotplog initial support in hotplug.c
4. added SMP support for PJ4B cpu

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp.dtsi    |    4 ++
 arch/arm/configs/mvebu_defconfig    |    3 +
 arch/arm/mach-mvebu/Kconfig         |    1 +
 arch/arm/mach-mvebu/Makefile        |    2 +
 arch/arm/mach-mvebu/armada-370-xp.c |    3 +
 arch/arm/mach-mvebu/common.h        |    3 +
 arch/arm/mach-mvebu/headsmp.S       |   66 +++++++++++++++++++
 arch/arm/mach-mvebu/hotplug.c       |   30 +++++++++
 arch/arm/mach-mvebu/platsmp.c       |  124 +++++++++++++++++++++++++++++++++++
 arch/arm/mm/proc-v7.S               |    3 +
 10 files changed, 239 insertions(+)
 create mode 100644 arch/arm/mach-mvebu/headsmp.S
 create mode 100644 arch/arm/mach-mvebu/hotplug.c
 create mode 100644 arch/arm/mach-mvebu/platsmp.c

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 531619f..7f968dc 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -38,24 +38,28 @@
 	    #size-cells = <0>;
 
 	    cpu at 0 {
+		device_type = "cpu";
 	       	compatible = "marvell,sheeva-v7";
 		reg = <0>;
 		clocks = <&cpuclk 0>;
 	    };
 
 	    cpu at 1 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <1>;
 		clocks = <&cpuclk 1>;
 	    };
 
 	    cpu at 2 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <2>;
 		clocks = <&cpuclk 2>;
 	    };
 
 	    cpu at 3 {
+		device_type = "cpu";
 		compatible = "marvell,sheeva-v7";
 		reg = <3>;
 		clocks = <&cpuclk 3>;
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 3458752..da598d3 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -12,6 +12,9 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 # CONFIG_CACHE_L2X0 is not set
+# CONFIG_SWP_EMULATE is not set
+CONFIG_SMP=y
+# CONFIG_LOCAL_TIMERS is not set
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 # CONFIG_COMPACTION is not set
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 9bfaa0c..d70afe3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -22,6 +22,7 @@ config MVEBU_CLK_CPU
 config MACH_ARMADA_370_XP
 	bool
 	select ARMADA_370_XP_TIMER
+	select HAVE_SMP
 	select CPU_PJ4B
 
 config MACH_ARMADA_370
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 8e6e50b..eb3cbd1 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -3,3 +3,5 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 
 obj-y += system-controller.o
 obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o pmsu.o
+obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
+obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..66befa1 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -22,6 +22,7 @@
 #include <asm/mach/time.h>
 #include "armada-370-xp.h"
 #include "common.h"
+#include "coherency.h"
 
 static struct map_desc armada_370_xp_io_desc[] __initdata = {
 	{
@@ -50,6 +51,7 @@ struct sys_timer armada_370_xp_timer = {
 static void __init armada_370_xp_dt_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	coherency_init();
 }
 
 static const char * const armada_370_xp_dt_board_dt_compat[] = {
@@ -59,6 +61,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
 };
 
 DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
+	.smp		= smp_ops(armada_xp_smp_ops),
 	.init_machine	= armada_370_xp_dt_init,
 	.map_io		= armada_370_xp_map_io,
 	.init_irq	= armada_370_xp_init_irq,
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 74ee0b2..86484bb 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -21,7 +21,10 @@ void mvebu_clocks_init(void);
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
 
+void armada_xp_cpu_die(unsigned int cpu);
 
 int armada_370_xp_coherency_init(void);
 int armada_370_xp_pmsu_init(void);
+void armada_xp_secondary_startup(void);
+extern struct smp_operations armada_xp_smp_ops;
 #endif
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
new file mode 100644
index 0000000..33db1d5
--- /dev/null
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -0,0 +1,66 @@
+/*
+ * SMP support: Entry point for secondary CPUs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This file implements the assembly entry point for secondary CPUs
+ * in an SMP kernel. The only thing we need to do is to add the CPU
+ * to the coherency fabric by writing to 2 registers. Currently these
+ * register addresses are hard coded due to the early initialisation problems.
+ */
+
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+/*
+ * At this stage the secondary CPUs don't have acces yet to the MMU, so
+ * we have to provide physical addresses
+ */
+#define ARMADA_XP_COHERENCY_FABRIC_CTL_REG 0xD0020200
+#define ARMADA_XP_COHERENCY_FABRIC_CFG_REG 0xD0020204
+
+	__INIT
+
+/*
+ * Armada XP specific entry point for secondary CPUs.
+ * We add the CPU to the coherency fabric and then jump to secondary
+ * startup
+ */
+
+ENTRY(armada_xp_secondary_startup)
+
+	/* Read CPU id */
+ 	mrc     p15, 0, r1, c0, c0, 5
+	and     r1, r1, #0xF
+
+	/* Add CPU to coherency fabric */
+
+	/* Create bit by cpu index */
+	mov     r2,r1
+	add     r2,r2,#24
+	mov     r3, #1
+	lsl     r3, r3, r2
+
+	/* Add CPU to SMP group - Atomic */
+	ldr     r0, = ARMADA_XP_COHERENCY_FABRIC_CTL_REG
+	ldr     r10, [r0]
+	orr     r10 , r10, r3
+	str	r10,[r0]
+
+	/* Enable coherency on CPU - Atomic*/
+	ldr     r0, = ARMADA_XP_COHERENCY_FABRIC_CFG_REG
+	ldr     r10, [r0]
+	orr     r10 , r10, r3
+	str     r10,[r0]
+
+	b	secondary_startup
+
+ENDPROC(armada_xp_secondary_startup)
diff --git a/arch/arm/mach-mvebu/hotplug.c b/arch/arm/mach-mvebu/hotplug.c
new file mode 100644
index 0000000..b228b6a
--- /dev/null
+++ b/arch/arm/mach-mvebu/hotplug.c
@@ -0,0 +1,30 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/smp.h>
+#include <asm/proc-fns.h>
+
+/*
+ * platform-specific code to shutdown a CPU
+ *
+ * Called with IRQs disabled
+ */
+void __ref armada_xp_cpu_die(unsigned int cpu)
+{
+	cpu_do_idle();
+
+	/* We should never return from idle */
+	panic("mvebu: cpu %d unexpectedly exit from shutdown\n", cpu);
+}
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
new file mode 100644
index 0000000..1cd6c08
--- /dev/null
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -0,0 +1,124 @@
+/*
+ * Symmetric Multi Processing (SMP) support for Armada XP
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The Armada XP SoC has 4 ARMv7 PJ4B CPUs running in full HW coherency
+ * This file implements the routines for preparing the SMP infrastructure
+ * and waking up the secondary CPUs
+ */
+
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_plat.h>
+#include "common.h"
+#include "armada-370-xp.h"
+#include "pmsu.h"
+#include "coherency.h"
+
+void __init set_secondary_cpus_clock(void)
+{
+	int cpu;
+	unsigned long rate;
+	struct clk *cpu_clk = NULL;
+	struct device_node *np = NULL;
+
+	cpu = smp_processor_id();
+	np = of_find_node_by_type(np, "cpu");
+	np = NULL;
+	while ((np = of_find_node_by_type(np, "cpu"))) {
+		const u32 *reg;
+		int len;
+		reg = of_get_property(np, "reg", &len);
+		if (!reg || len != 4) {
+			pr_err("%s missing reg property\n", np->full_name);
+			continue;
+		}
+		if (be32_to_cpup(reg) == cpu) {
+			cpu_clk = of_clk_get(np, 0);
+			break;
+		}
+	}
+	WARN_ON(IS_ERR(cpu_clk));
+	clk_prepare_enable(cpu_clk);
+	rate = clk_get_rate(cpu_clk);
+
+	/* set all the other CPU clk to the same rate than the boot CPU */
+	np = NULL;
+	while ((np = of_find_node_by_type(np, "cpu"))) {
+		const u32 *reg;
+		int len;
+		reg = of_get_property(np, "reg", &len);
+		if (!reg || len != 4) {
+			pr_err("%s missing reg property\n", np->full_name);
+			continue;
+		}
+		if (be32_to_cpup(reg) != cpu) {
+			cpu_clk = of_clk_get(np, 0);
+			clk_set_rate(cpu_clk, rate);
+		}
+	}
+}
+
+static void __cpuinit armada_xp_secondary_init(unsigned int cpu)
+{
+	armada_xp_mpic_smp_cpu_init();
+}
+
+static int __cpuinit armada_xp_boot_secondary(unsigned int cpu,
+					      struct task_struct *idle)
+{
+	pr_info("Booting CPU %d\n", cpu);
+
+	armada_xp_boot_cpu(cpu, armada_xp_secondary_startup);
+
+	return 0;
+}
+
+static void __init armada_xp_smp_init_cpus(void)
+{
+	unsigned int i, ncores;
+	ncores = coherency_get_cpu_count();
+
+	/* Limit possbile CPUs to defconfig */
+	if (ncores > nr_cpu_ids) {
+		pr_warn("SMP: %d CPUs physically present. Only %d configured.",
+			ncores, nr_cpu_ids);
+		pr_warn("Clipping CPU count to %d\n", nr_cpu_ids);
+		ncores = nr_cpu_ids;
+	}
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+
+	set_smp_cross_call(armada_mpic_send_doorbell);
+}
+
+void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
+{
+	set_secondary_cpus_clock();
+	flush_cache_all();
+	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+}
+
+struct smp_operations armada_xp_smp_ops __initdata = {
+	.smp_init_cpus		= armada_xp_smp_init_cpus,
+	.smp_prepare_cpus	= armada_xp_smp_prepare_cpus,
+	.smp_secondary_init	= armada_xp_secondary_init,
+	.smp_boot_secondary	= armada_xp_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_die		= armada_xp_cpu_die,
+#endif
+};
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 1a373c2..dcd97e4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -191,6 +191,9 @@ __v7_pj4b_setup:
 
 	/* Auxiliary Functional Modes Control Register 0 */
 	mrc	p15, 1,	r0, c15, c2, 0
+#ifdef CONFIG_SMP
+	orr	r0, r0, #(1 << 1)     @ Set SMP mode. Join the coherency fabric
+#endif
 	orr	r0, r0, #(1 << 2)     @ Support L1 parity checking
 	orr	r0, r0, #(1 << 8)     @ Broadcast Cache and TLB maintenance
 	mcr	p15, 1,	r0, c15, c2, 0
-- 
1.7.9.5

Re: [PATCH V2 0/5] SMP support for Armada XP

[Gregory CLEMENT]

Hello,

On 10/29/2012 10:11 PM, Gregory CLEMENT wrote:
[...]

> Arnd, Olof, as this code is SoC specific will you be able to pull it
> through Jason tree? Or should I push the part added in
> arch/arm/mm/proc-v7.S to support PJ4B CPU through Russell tree?

Before sending a new series with the fixes related to Will comments, I
would like to know if I need to split the patches in order to send some
parts to Russell or if you (Arnd and Olof) will be able to take the whole
series (through Jason Cooper's git tree of course).

> 
> Changelog:
> V1 -> V2:
> - Rebased on to v3.7-rc3
> - Fixed typos found by Alexandre Belloni
> - Added clk_prepare_enable() before getting rate clk in
>   set_secondary_cpus_clock()
> - Add explanation in the binding documentation about the per-CPU
>   interrupt registers: the address of the virtual register must be
>   used.
> - Removed the armada_xp prefix in the coherency.c file to be more
>   compliant with the name convention of the other files.
> - Coherency_init is now called from armada_370_xp_dt_init() and is no
>   more an early_init() call. As the device tree is not available from
>   an early_init(), it was useless to call coherency_init() so
>   early. The need to be able to call some function very early during
>   the boot were already resolved by using the hard code address of the
>   register.
> 
> Regards,
> 
> Yehuda Yitschak (5):
>   arm: mvebu: Added support for coherency fabric in mach-mvebu
>   arm: mvebu: Added initial support for power managmement service unit
>   arm: mvebu: Added IPI support via doorbells
>   arm: mm: Added support for PJ4B cpu and init routines
>   arm: mvebu: Added SMP support for Armada XP
> 
>  .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 +-
>  .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 ++++
>  .../devicetree/bindings/arm/coherency-fabric.txt   |   16 +++
>  arch/arm/boot/dts/armada-370-xp.dtsi               |    5 +
>  arch/arm/boot/dts/armada-xp.dtsi                   |   12 +-
>  arch/arm/configs/mvebu_defconfig                   |    3 +
>  arch/arm/mach-mvebu/Kconfig                        |    3 +-
>  arch/arm/mach-mvebu/Makefile                       |    4 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |    3 +
>  arch/arm/mach-mvebu/armada-370-xp.h                |   10 ++
>  arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++
>  arch/arm/mach-mvebu/coherency.h                    |   21 ++++
>  arch/arm/mach-mvebu/common.h                       |    6 +
>  arch/arm/mach-mvebu/headsmp.S                      |   66 +++++++++++
>  arch/arm/mach-mvebu/hotplug.c                      |   30 +++++
>  arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++-
>  arch/arm/mach-mvebu/platsmp.c                      |  124 ++++++++++++++++++++
>  arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++
>  arch/arm/mach-mvebu/pmsu.h                         |   16 +++
>  arch/arm/mm/Kconfig                                |    4 +
>  arch/arm/mm/proc-v7.S                              |   46 ++++++++
>  21 files changed, 648 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
>  create mode 100644 arch/arm/mach-mvebu/coherency.c
>  create mode 100644 arch/arm/mach-mvebu/coherency.h
>  create mode 100644 arch/arm/mach-mvebu/headsmp.S
>  create mode 100644 arch/arm/mach-mvebu/hotplug.c
>  create mode 100644 arch/arm/mach-mvebu/platsmp.c
>  create mode 100644 arch/arm/mach-mvebu/pmsu.c
>  create mode 100644 arch/arm/mach-mvebu/pmsu.h
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH V2 0/5] SMP support for Armada XP

[Gregory CLEMENT]

Hello,

On 10/29/2012 10:11 PM, Gregory CLEMENT wrote:
[...]

> Arnd, Olof, as this code is SoC specific will you be able to pull it
> through Jason tree? Or should I push the part added in
> arch/arm/mm/proc-v7.S to support PJ4B CPU through Russell tree?

Before sending a new series with the fixes related to Will comments, I
would like to know if I need to split the patches in order to send some
parts to Russell or if you (Arnd and Olof) will be able to take the whole
series (through Jason Cooper's git tree of course).

> 
> Changelog:
> V1 -> V2:
> - Rebased on to v3.7-rc3
> - Fixed typos found by Alexandre Belloni
> - Added clk_prepare_enable() before getting rate clk in
>   set_secondary_cpus_clock()
> - Add explanation in the binding documentation about the per-CPU
>   interrupt registers: the address of the virtual register must be
>   used.
> - Removed the armada_xp prefix in the coherency.c file to be more
>   compliant with the name convention of the other files.
> - Coherency_init is now called from armada_370_xp_dt_init() and is no
>   more an early_init() call. As the device tree is not available from
>   an early_init(), it was useless to call coherency_init() so
>   early. The need to be able to call some function very early during
>   the boot were already resolved by using the hard code address of the
>   register.
> 
> Regards,
> 
> Yehuda Yitschak (5):
>   arm: mvebu: Added support for coherency fabric in mach-mvebu
>   arm: mvebu: Added initial support for power managmement service unit
>   arm: mvebu: Added IPI support via doorbells
>   arm: mm: Added support for PJ4B cpu and init routines
>   arm: mvebu: Added SMP support for Armada XP
> 
>  .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   12 +-
>  .../devicetree/bindings/arm/armada-370-xp-pmsu.txt |   20 ++++
>  .../devicetree/bindings/arm/coherency-fabric.txt   |   16 +++
>  arch/arm/boot/dts/armada-370-xp.dtsi               |    5 +
>  arch/arm/boot/dts/armada-xp.dtsi                   |   12 +-
>  arch/arm/configs/mvebu_defconfig                   |    3 +
>  arch/arm/mach-mvebu/Kconfig                        |    3 +-
>  arch/arm/mach-mvebu/Makefile                       |    4 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |    3 +
>  arch/arm/mach-mvebu/armada-370-xp.h                |   10 ++
>  arch/arm/mach-mvebu/coherency.c                    |   89 ++++++++++++++
>  arch/arm/mach-mvebu/coherency.h                    |   21 ++++
>  arch/arm/mach-mvebu/common.h                       |    6 +
>  arch/arm/mach-mvebu/headsmp.S                      |   66 +++++++++++
>  arch/arm/mach-mvebu/hotplug.c                      |   30 +++++
>  arch/arm/mach-mvebu/irq-armada-370-xp.c            |   92 ++++++++++++++-
>  arch/arm/mach-mvebu/platsmp.c                      |  124 ++++++++++++++++++++
>  arch/arm/mach-mvebu/pmsu.c                         |   78 ++++++++++++
>  arch/arm/mach-mvebu/pmsu.h                         |   16 +++
>  arch/arm/mm/Kconfig                                |    4 +
>  arch/arm/mm/proc-v7.S                              |   46 ++++++++
>  21 files changed, 648 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
>  create mode 100644 arch/arm/mach-mvebu/coherency.c
>  create mode 100644 arch/arm/mach-mvebu/coherency.h
>  create mode 100644 arch/arm/mach-mvebu/headsmp.S
>  create mode 100644 arch/arm/mach-mvebu/hotplug.c
>  create mode 100644 arch/arm/mach-mvebu/platsmp.c
>  create mode 100644 arch/arm/mach-mvebu/pmsu.c
>  create mode 100644 arch/arm/mach-mvebu/pmsu.h
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH V2 0/5] SMP support for Armada XP

[Arnd Bergmann]

On Monday 12 November 2012, Gregory CLEMENT wrote:
> Before sending a new series with the fixes related to Will comments, I
> would like to know if I need to split the patches in order to send some
> parts to Russell or if you (Arnd and Olof) will be able to take the whole
> series (through Jason Cooper's git tree of course).
> 

We can take the whole series through arm-soc, but it would be good to
get an Ack from Russell for patch 4.

	Arnd

[PATCH V2 0/5] SMP support for Armada XP

[Arnd Bergmann]

On Monday 12 November 2012, Gregory CLEMENT wrote:
> Before sending a new series with the fixes related to Will comments, I
> would like to know if I need to split the patches in order to send some
> parts to Russell or if you (Arnd and Olof) will be able to take the whole
> series (through Jason Cooper's git tree of course).
> 

We can take the whole series through arm-soc, but it would be good to
get an Ack from Russell for patch 4.

	Arnd