SMP support for Armada XP

arch/arm/mach-mvebu/coherency.c new file +18 -0

new file mode 100644
index 0000000..69e130d
@@ -0,0 +1,89 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <[email protected]>
+ * Gregory Clement <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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
+ */

arch/arm/mach-mvebu/coherency.c new file +12 -0

+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);

Hi Gregory,

Quoted 24 lines

arch/arm/mach-mvebu/coherency.c new file +18 -0

new file mode 100644
index 0000000..69e130d
@@ -0,0 +1,89 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <[email protected]>
+ * Gregory Clement <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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
+ */

[...]

Quoted 19 lines

arch/arm/mach-mvebu/coherency.c new file +19 -0

+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);

arch/arm/mach-mvebu/coherency.c line 76

Quoted 3 lines

arch/arm/mach-mvebu/coherency.c new file +3 -0

+
+	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

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

Hi Gregory,

Quoted 24 lines · Gregory CLEMENT

arch/arm/mach-mvebu/coherency.c new file +18 -0

new file mode 100644
index 0000000..69e130d
@@ -0,0 +1,89 @@
+/*
+ * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <[email protected]>
+ * Gregory Clement <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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
+ */

[...]

Quoted 19 lines

arch/arm/mach-mvebu/coherency.c new file +19 -0

+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);

arch/arm/mach-mvebu/coherency.c line 76

Quoted 3 lines

arch/arm/mach-mvebu/coherency.c new file +3 -0

+
+	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?

Quoted 20 lines · Will Deacon

Quoted 19 lines · Gregory CLEMENT

arch/arm/mach-mvebu/coherency.c new file +19 -0

+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);

Quoted 8 lines

arch/arm/mach-mvebu/coherency.c line 76

Quoted 3 lines

arch/arm/mach-mvebu/coherency.c new file +3 -0

+
+	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.

Quoted 30 lines · Gregory CLEMENT

Quoted 28 lines · Will Deacon

Quoted 12 lines · Gregory CLEMENT

arch/arm/mach-mvebu/coherency.c new file +12 -0

+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);

arch/arm/mach-mvebu/coherency.c line 76

Quoted 10 lines

arch/arm/mach-mvebu/coherency.c new file +10 -0

+	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?

Quoted 4 lines

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.

Quoted 12 lines · Will Deacon

Quoted 10 lines · Gregory CLEMENT

Quoted 4 lines · Will Deacon

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.

Quoted 4 lines

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."

Quoted 18 lines · Gregory CLEMENT

Quoted 16 lines · Will Deacon

Quoted 10 lines · Gregory CLEMENT

Quoted 4 lines · Will Deacon

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.

Quoted 3 lines

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?

Quoted 1 line · Will Deacon

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

Here come the answers to your new questions

Quoted 3 lines

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.

Quoted 2 lines

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."

Hi Gregory,

Quoted 4 lines · Gregory CLEMENT

Quoted 1 line · Will Deacon

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!

Quoted 6 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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).

Quoted 7 lines · Will Deacon

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.

Quoted 22 lines · Gregory CLEMENT

Quoted 7 lines · Will Deacon

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.

Quoted 1 line

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

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

Quoted 4 lines · Will Deacon

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.

arch/arm/mach-mvebu/pmsu.c new file +40 -0

new file mode 100644
index 0000000..cee020b
@@ -0,0 +1,78 @@
+/*
+ * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <[email protected]>
+ * Gregory Clement <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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;

Quoted 4 lines · Gregory CLEMENT

arch/arm/mach-mvebu/pmsu.c new file +4 -0

+#ifdef CONFIG_SMP
+int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
+{
+	int reg, hw_cpu;

arch/arm/mach-mvebu/pmsu.c line 50

Quoted 10 lines

arch/arm/mach-mvebu/pmsu.c new file +10 -0

+
+	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...

arch/arm/mach-mvebu/pmsu.c line 53

Quoted 2 lines

arch/arm/mach-mvebu/pmsu.c new file +2 -0

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

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

Quoted 5 lines · Will Deacon

arch/arm/mach-mvebu/pmsu.c line 53

Quoted 2 lines · Gregory CLEMENT

arch/arm/mach-mvebu/pmsu.c new file +2 -0

+	/* 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.

From: Yehuda Yitschak <[email protected]>

Signed-off-by Yehuda Yitschak <[email protected]>

Signed-off-by Gregory CLEMENT <[email protected]>

---
 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(-)

arch/arm/mach-mvebu/Kconfig +1 -1

index 17d246b..9bfaa0c 100644
@@ -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"

arch/arm/mm/Kconfig +4 -0

index 94186b6..3fd629d 100644
@@ -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

arch/arm/mm/proc-v7.S +43 -0

index 846d279..1a373c2 100644
@@ -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 */
 
 	/*

Quoted 7 lines

__v7_setup:

arch/arm/mm/proc-v7.S +0 -0

 	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

arch/arm/mm/proc-v7.S __v7_ca9mp_proc_info: · line 385

Quoted 8 lines

arch/arm/mm/proc-v7.S +8 -0

+
+	/*
+	 * Marvell PJ4B processor.
+	 */
+	.type   __v7_pj4b_proc_info, #object
+__v7_pj4b_proc_info:
+	.long	0x562f5842
+	.long	0xffffffff

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

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).