* [PATCH V2 0/5] SMP support for Armada XP
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-10-29 21:11 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, Ike Pan, Will Deacon, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Arnd Bergmann, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-11-05 14:02 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-05 14:02 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Mike Turquette,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-05 14:02 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-05 14:02 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-05 14:02 ` Will Deacon
@ 2012-11-05 23:53 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-05 23:53 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-05 23:53 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-05 23:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-05 14:02 ` Will Deacon
@ 2012-11-12 20:21 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-12 20:21 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-12 20:21 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-12 20:21 ` Gregory CLEMENT
@ 2012-11-13 10:43 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-13 10:43 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-13 10:43 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-13 10:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-13 10:43 ` Will Deacon
@ 2012-11-14 20:00 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-14 20:00 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Mike Turquette,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-14 20:00 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-14 20:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-14 20:00 ` Gregory CLEMENT
@ 2012-11-15 10:17 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-15 10:17 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Mike Turquette,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-15 10:17 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-15 10:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-15 10:17 ` Will Deacon
@ 2012-11-15 15:54 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-15 15:54 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-15 15:54 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-15 15:54 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-15 15:54 ` Gregory CLEMENT
@ 2012-11-15 16:21 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-15 16:21 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-15 16:21 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-15 16:21 ` Will Deacon
@ 2012-11-15 16:49 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-15 16:49 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-15 16:49 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-15 16:49 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-15 16:49 ` Gregory CLEMENT
@ 2012-11-16 18:56 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-16 18:56 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Russell King,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-16 18:56 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-16 18:56 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <20121116185610.GA1019-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>]
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-16 18:56 ` Will Deacon
@ 2012-11-16 19:25 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-16 19:25 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, jcm-H+wXaHxf7aLQT0dZR+AlfA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Ben Dooks, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-16 19:25 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-16 19:25 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <50A69341.2090202-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
2012-11-16 19:25 ` Gregory CLEMENT
@ 2012-11-19 10:32 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-19 10:32 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, jcm-H+wXaHxf7aLQT0dZR+AlfA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Ben Dooks, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
@ 2012-11-19 10:32 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-19 10:32 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-10-29 21:11 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, Ike Pan, Will Deacon, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Arnd Bergmann, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-11-05 14:05 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-05 14:05 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Mike Turquette,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
@ 2012-11-05 14:05 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-05 14:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
2012-11-05 14:05 ` Will Deacon
@ 2012-11-14 0:07 ` Russell King - ARM Linux
-1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-11-14 0:07 UTC (permalink / raw)
To: Will Deacon
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Gregory CLEMENT,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
@ 2012-11-14 0:07 ` Russell King - ARM Linux
0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-11-14 0:07 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
2012-11-14 0:07 ` Russell King - ARM Linux
@ 2012-11-14 9:46 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-14 9:46 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Mike Turquette,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Gregory CLEMENT,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
@ 2012-11-14 9:46 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-14 9:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 3/5] arm: mvebu: Added IPI support via doorbells
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-10-29 21:11 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, Ike Pan, Will Deacon, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Arnd Bergmann, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 3/5] arm: mvebu: Added IPI support via doorbells
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-10-29 21:11 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, Ike Pan, Will Deacon, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Arnd Bergmann, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-11-13 15:15 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-13 15:15 UTC (permalink / raw)
To: Russell King
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Will Deacon, Nadav Haklai,
Ian Molton, David Marlin, Yehuda Yitschak, Jani Monoses,
Mike Turquette, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper,
Arnd Bergmann, Jon Masters, devicetree-discuss, Rob Herring,
Ben Dooks, linux-arm-kernel, Thomas Petazzoni, Chris
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
@ 2012-11-13 15:15 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-13 15:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
2012-11-13 15:15 ` Gregory CLEMENT
@ 2012-11-13 22:53 ` Will Deacon
-1 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-13 22:53 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Jason Cooper, Arnd Bergmann, jcm,
devicetree-discuss, rob.herring, Ben Dooks, Mike Turquette,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
@ 2012-11-13 22:53 ` Will Deacon
0 siblings, 0 replies; 52+ messages in thread
From: Will Deacon @ 2012-11-13 22:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-11-14 0:14 ` Russell King - ARM Linux
-1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-11-14 0:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Will Deacon, Nadav Haklai,
Ian Molton, David Marlin, Yehuda Yitschak, Jani Monoses,
Mike Turquette, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper,
Arnd Bergmann, Jon Masters, devicetree-discuss, Rob Herring,
Ben Dooks, linux-arm-kernel, Thomas Petazzoni, Chris
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 :)
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
@ 2012-11-14 0:14 ` Russell King - ARM Linux
0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2012-11-14 0:14 UTC (permalink / raw)
To: linux-arm-kernel
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 :)
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 5/5] arm: mvebu: Added SMP support for Armada XP
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-10-29 21:11 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, Ike Pan, Will Deacon, Nadav Haklai, Ian Molton,
David Marlin, Yehuda Yitschak, Jani Monoses, Russell King,
Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Leif Lindholm,
Sebastian Hesselbarth, Arnd Bergmann, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH V2 5/5] arm: mvebu: Added SMP support for Armada XP
@ 2012-10-29 21:11 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-10-29 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH V2 0/5] SMP support for Armada XP
2012-10-29 21:11 ` Gregory CLEMENT
@ 2012-11-12 20:49 ` Gregory CLEMENT
-1 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-12 20:49 UTC (permalink / raw)
To: Gregory CLEMENT, Arnd Bergmann, Olof Johansson, Russell King
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Will Deacon, Nadav Haklai,
Ian Molton, David Marlin, Yehuda Yitschak, Jani Monoses,
Mike Turquette, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, linux-arm-kernel,
Thomas Petazzoni, Chris Van Hoof
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 0/5] SMP support for Armada XP
@ 2012-11-12 20:49 ` Gregory CLEMENT
0 siblings, 0 replies; 52+ messages in thread
From: Gregory CLEMENT @ 2012-11-12 20:49 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH V2 0/5] SMP support for Armada XP
2012-11-12 20:49 ` Gregory CLEMENT
@ 2012-11-12 22:32 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2012-11-12 22:32 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Will Deacon, Nadav Haklai,
Ian Molton, David Marlin, Yehuda Yitschak, Jani Monoses,
Russell King, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper, Jon Masters,
devicetree-discuss, Rob Herring, Ben Dooks, Mike Turquette,
linux-arm-kernel, Thomas Petazzoni
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH V2 0/5] SMP support for Armada XP
@ 2012-11-12 22:32 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2012-11-12 22:32 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread