Skip to contentSkip to conversation

ARM: mvebu: no I/O coherency on non-SMP and related updates

PATCH Superseded Thomas Petazzoni 3 participants 12 messages Nov 13, 2014 – Nov 22, 2014

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

v3 cover ARM: mvebu: no I/O coherency on non-SMP and related updates

Hello,

This series makes a number of updates to the I/O coherency code of Marvell EBU platforms.

Changes since v2:

- Drop patch "ARM: mvebu: add missing of_node_put() call in coherency.c" since it was merged.

- Update "make the coherency_ll.S functions work with no coherency fabric" to use "reteq <reg>" instead of "moveq pc, <reg>", as suggested by Gr?gory Clement.

- Update the comment in "disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP" to give more details about what would be needed to get HW I/O coherency working on Armada 370, as suggested by Jason Cooper.

- Added Acked-by from Gr?gory Clement as appropriate.

- Added one patch to drop the Armada 375 Z1 workaround for I/O coherency, which removes a significant chunk of code from coherency.c.

- Added two patches doing minor cleanup/updates to coherency.c

Changes since v1:

- Rebased on top of v3.18-rc2.
- Added some Fixes:/Cc: tags on the last patch to get it merged into the stable tree, as it fixes a real DT reference count leak.

Best regards,

Thomas Petazzoni

Thomas Petazzoni (5):
ARM: mvebu: make the coherency_ll.S functions work with no coherency
fabric
ARM: mvebu: disable I/O coherency on non-SMP situations on Armada

    370/375/38x/XP

ARM: mvebu: remove unused register offset definition
ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency
ARM: mvebu: update comments in coherency.c

 arch/arm/mach-mvebu/coherency.c    | 220 ++++++-------------------------------
 arch/arm/mach-mvebu/coherency_ll.S |  21 +++-
 2 files changed, 55 insertions(+), 186 deletions(-)
Signature · 1 line
2.0.0
#1 lore raw

PATCH v3 1/5 ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric

The ll_add_cpu_to_smp_group(), ll_enable_coherency() and ll_disable_coherency() are used on Armada XP to control the coherency fabric. However, they make the assumption that the coherency fabric is always available, which is currently a correct assumption but will no longer be true with a followup commit that disables the usage of the coherency fabric when the conditions are not met to use it.

Therefore, this commit modifies those functions so that they check the return value of ll_get_coherency_base(), and if the return value is 0, they simply return without configuring anything in the coherency fabric.

The ll_get_coherency_base() function is also modified to properly return 0 when the function is called with the MMU disabled. In this case, it normally returns the physical address of the coherency fabric, but we now check if the virtual address is 0, and if that's case, return a physical address of 0 to indicate that the coherency fabric is not enabled.

---
 arch/arm/mach-mvebu/coherency_ll.S | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)
arch/arm/mach-mvebu/coherency_ll.S +19 -2
index f5d881b..8b2fbc8 100644
@@ -24,7 +24,10 @@
 #include <asm/cp15.h>
 
 	.text
-/* Returns the coherency base address in r1 (r0 is untouched) */
+/*
+ * Returns the coherency base address in r1 (r0 is untouched), or 0 if
+ * the coherency fabric is not enabled.
+ */
 ENTRY(ll_get_coherency_base)
 	mrc	p15, 0, r1, c1, c0, 0
 	tst	r1, #CR_M @ Check MMU bit enabled
@@ -32,8 +35,13 @@ ENTRY(ll_get_coherency_base)
 
 	/*
 	 * MMU is disabled, use the physical address of the coherency
-	 * base address.
+	 * base address. However, if the coherency fabric isn't mapped
+	 * (i.e its virtual address is zero), it means coherency is
+	 * not enabled, so we return 0.
 	 */
+	ldr	r1, =coherency_base
+	cmp	r1, #0
+	beq	2f
 	adr	r1, 3f
 	ldr	r3, [r1]
 	ldr	r1, [r1, r3]
@@ -85,6 +93,9 @@ ENTRY(ll_add_cpu_to_smp_group)
 	 */
 	mov 	r0, lr
 	bl	ll_get_coherency_base
+	/* Bail out if the coherency is not enabled */
+	cmp	r1, #0
+	reteq	r0
 	bl	ll_get_coherency_cpumask
 	mov 	lr, r0
 	add	r0, r1, #ARMADA_XP_CFB_CFG_REG_OFFSET
@@ -107,6 +118,9 @@ ENTRY(ll_enable_coherency)
 	 */
 	mov r0, lr
 	bl	ll_get_coherency_base
+	/* Bail out if the coherency is not enabled */
+	cmp	r1, #0
+	reteq	r0
 	bl	ll_get_coherency_cpumask
 	mov lr, r0
 	add	r0, r1, #ARMADA_XP_CFB_CTL_REG_OFFSET
@@ -131,6 +145,9 @@ ENTRY(ll_disable_coherency)
 	 */
 	mov 	r0, lr
 	bl	ll_get_coherency_base
+	/* Bail out if the coherency is not enabled */
+	cmp	r1, #0
+	reteq	r0
 	bl	ll_get_coherency_cpumask
 	mov 	lr, r0
 	add	r0, r1, #ARMADA_XP_CFB_CTL_REG_OFFSET
Signature · 1 line
2.0.0
#2 lore raw

PATCH v3 2/5 ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

In reply to Thomas Petazzoni

Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada 38x and Armada XP requires a certain number of conditions:

- On Armada 370, the cache policy must be set to write-allocate.

- On Armada 375, 38x and XP, the cache policy must be set to write-allocate, the pages must be mapped with the shareable attribute, and the SMP bit must be set

Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP or !CONFIG_SMP is used, the cache policy will be set to write-back by the kernel and not write-allocate.

Since solving this problem turns out to be quite complicated, and we don't want to let users with a mainline kernel known to have infrequent but existing data corruptions, this commit proposes to simply disable hardware I/O coherency in situations where it is known not to work.

And basically, the is_smp() function of the kernel tells us whether it is OK to enable hardware I/O coherency or not, so this commit slightly refactors the coherency_type() function to return COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate type of the coherency fabric in the other case.

Thanks to this, the I/O coherency fabric will no longer be used at all in !CONFIG_SMP configurations. It will continue to be used in CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x (which are multiple cores processors), but will no longer be used on Armada 370 (which is a single core processor).

In the process, it simplifies the implementation of the coherency_type() function, and adds a missing call to of_node_put().

Fixes e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O Coherency support")
Cc <[email protected]> # v3.8+
---
 arch/arm/mach-mvebu/coherency.c | 44 ++++++++++++++++++++++++++++-------------
 1 file changed, 30 insertions(+), 14 deletions(-)
arch/arm/mach-mvebu/coherency.c +30 -14
index 044b511..c31f4c0 100644
@@ -361,25 +361,41 @@ static int coherency_type(void)
 {
 	struct device_node *np;
 	const struct of_device_id *match;
+	int type;
 
-	np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
-	if (np) {
-		int type = (int) match->data;
+	/*
+	 * The coherency fabric is needed:
+	 * - For coherency between processors on Armada XP, so only
+	 *   when SMP is enabled.
+	 * - For coherency between the processor and I/O devices, but
+	 *   this coherency requires many pre-requisites (write
+	 *   allocate cache policy, shareable pages, SMP bit set) that
+	 *   are only meant in SMP situations.
+	 *
+	 * Note that this means that on Armada 370, there is currently
+	 * no way to use hardware I/O coherency, because even when
+	 * CONFIG_SMP is enabled, is_smp() returns false due to the
+	 * Armada 370 being a single-core processor. To lift this
+	 * limitation, we would have to find a way to make the cache
+	 * policy set to write-allocate (on all Armada SoCs), and to
+	 * set the shareable attribute in page tables (on all Armada
+	 * SoCs except the Armada 370). Unfortunately, such decisions
+	 * are taken very early in the kernel boot process, at a point
+	 * where we don't know yet on which SoC we are running.
 
-		/* Armada 370/XP coherency works in both UP and SMP */
-		if (type == COHERENCY_FABRIC_TYPE_ARMADA_370_XP)
-			return type;
+	 */
+	if (!is_smp())
+		return COHERENCY_FABRIC_TYPE_NONE;
 
-		/* Armada 375 coherency works only on SMP */
-		else if (type == COHERENCY_FABRIC_TYPE_ARMADA_375 && is_smp())
-			return type;
+	np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
+	if (!np)
+		return COHERENCY_FABRIC_TYPE_NONE;
 
-		/* Armada 380 coherency works only on SMP */
-		else if (type == COHERENCY_FABRIC_TYPE_ARMADA_380 && is_smp())
-			return type;
-	}
+	type = (int) match->data;
+
+	of_node_put(np);
 
-	return COHERENCY_FABRIC_TYPE_NONE;
+	return type;
 }
 
 int coherency_available(void)
Signature · 1 line
2.0.0
#3 lore raw

PATCH v3 2/5 ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

Quoted 34 lines · On Thursday 13 November 2014 10:38:57 Thomas Petazzoni wrote:

Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada 38x and Armada XP requires a certain number of conditions:

- On Armada 370, the cache policy must be set to write-allocate.

- On Armada 375, 38x and XP, the cache policy must be set to write-allocate, the pages must be mapped with the shareable attribute, and the SMP bit must be set

Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP or !CONFIG_SMP is used, the cache policy will be set to write-back by the kernel and not write-allocate.

Since solving this problem turns out to be quite complicated, and we don't want to let users with a mainline kernel known to have infrequent but existing data corruptions, this commit proposes to simply disable hardware I/O coherency in situations where it is known not to work.

And basically, the is_smp() function of the kernel tells us whether it is OK to enable hardware I/O coherency or not, so this commit slightly refactors the coherency_type() function to return COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate type of the coherency fabric in the other case.

Thanks to this, the I/O coherency fabric will no longer be used at all in !CONFIG_SMP configurations. It will continue to be used in CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x (which are multiple cores processors), but will no longer be used on Armada 370 (which is a single core processor).

Quoted 8 lines

In the process, it simplifies the implementation of the coherency_type() function, and adds a missing call to of_node_put().

Fixes e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O Coherency support")
Cc <[email protected]> # v3.8+

Seems fine to me. I was hoping to solve this with the introduction of the CONFIG_ARCH_MULTIPLATFORM_STRICT or CONFIG_BROKEN_MULTIPLATFORM setting that would allow us to have a compile-time setting to make it work on UP (while possibly breaking or slowing down other machines in a multiplatform kernel), but Russell didn't like the idea.

Arnd

#4 lore raw

PATCH v3 2/5 ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

Dear Arnd Bergmann,

Quoted 5 lines · Arnd Bergmann

Seems fine to me. I was hoping to solve this with the introduction of the CONFIG_ARCH_MULTIPLATFORM_STRICT or CONFIG_BROKEN_MULTIPLATFORM setting that would allow us to have a compile-time setting to make it work on UP (while possibly breaking or slowing down other machines in a multiplatform kernel), but Russell didn't like the idea.

Right. Unfortunately, I don't currently see a good way of handling such a case, other than having the C code at some point in the initialization re-create all the page tables that were set up by the assembly code. The basic problem here is that I need access to an information located in the Device Tree at a moment where the DT isn't available. So there are two options: 1/ make the DT available earlier, but it really seems impractical to manipulate the DT in the early assembly code, or 2/ make sure that the initialization done in the assembly code can be overridden later.

What do you think?

Best regards,

Thomas

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

PATCH v3 2/5 ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

Quoted 18 lines · On Thursday 13 November 2014 11:17:30 Thomas Petazzoni wrote:
Quoted 5 lines · Arnd Bergmann

Seems fine to me. I was hoping to solve this with the introduction of the CONFIG_ARCH_MULTIPLATFORM_STRICT or CONFIG_BROKEN_MULTIPLATFORM setting that would allow us to have a compile-time setting to make it work on UP (while possibly breaking or slowing down other machines in a multiplatform kernel), but Russell didn't like the idea.

Right. Unfortunately, I don't currently see a good way of handling such a case, other than having the C code at some point in the initialization re-create all the page tables that were set up by the assembly code. The basic problem here is that I need access to an information located in the Device Tree at a moment where the DT isn't available. So there are two options: 1/ make the DT available earlier, but it really seems impractical to manipulate the DT in the early assembly code, or 2/ make sure that the initialization done in the assembly code can be overridden later.

Quoted 1 line

What do you think?

IIRC there is still an unsolved problem on mach-keystone that is somewhat related, they also have to change the page tables and the current method appears to be racy. Once that is solved, you might be able to do 2.

The approach I had in mind was much simpler, introducing a compile-time option that hardcodes the behavior you need for Armada-370 when set, knowing that you should not set that on any kernel that is supposed to run on other platforms.

Arnd

#6 lore raw

PATCH v3 2/5 ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP

Dear Arnd Bergmann,

Quoted 5 lines · Arnd Bergmann
Quoted 1 line

What do you think?

IIRC there is still an unsolved problem on mach-keystone that is somewhat related, they also have to change the page tables and the current method appears to be racy. Once that is solved, you might be able to do 2.

So maybe we need to invest time on this. I'll see how critical it is for us to have HW I/O coherency working on non-SMP configurations, and therefore if we can spend some time to work on this topic.

Quoted 4 lines

The approach I had in mind was much simpler, introducing a compile-time option that hardcodes the behavior you need for Armada-370 when set, knowing that you should not set that on any kernel that is supposed to run on other platforms.

Yes, I understood it was a compile-time option.

Actually, switching to the write-allocate cache policy, and on SoCs that support it, to shareable pages, will continue to work on other platforms. So it does not break them, even though it might maybe cause some performance penalties (even though I'm not even sure that it would be the case). So it's not completely incompatible with doing a multi-platform kernel.

Best regards,

Thomas

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

PATCH v3 3/5 ARM: mvebu: remove unused register offset definition

In reply to Thomas Petazzoni

Since commit b21dcafea36d ("arm: mvebu: remove dependency of SMP init on static I/O mapping"), the COHERENCY_FABRIC_CFG_OFFSET register offset definition is no longer used, so this commit removes it.

---
 arch/arm/mach-mvebu/coherency.c | 2 --
 1 file changed, 2 deletions(-)
arch/arm/mach-mvebu/coherency.c +0 -2
index c31f4c0..db2f5bd 100644
@@ -42,8 +42,6 @@ void __iomem *coherency_base;
 static void __iomem *coherency_cpu_base;
 
 /* Coherency fabric registers */
-#define COHERENCY_FABRIC_CFG_OFFSET		   0x4
-
 #define IO_SYNC_BARRIER_CTL_OFFSET		   0x0
 
 enum {
Signature · 1 line
2.0.0
#8 lore raw

PATCH v3 4/5 ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency

In reply to Thomas Petazzoni

This reverts commit 5ab5afd8ba83 ("ARM: mvebu: implement Armada 375 coherency workaround"), since we are removing the support for the very early Z1 revision of the Armada 375 SoC.

This commit is an exact revert, with two exceptions:

- minor adaptations needed due to other changes that have taken place in coherency.c since the original commit

- keep the definition of pr_fmt. This shouldn't originally have been part of the Armada 375 Z1 workaround commit since it had nothing to do with it.

---
 arch/arm/mach-mvebu/coherency.c | 169 +---------------------------------------
 1 file changed, 3 insertions(+), 166 deletions(-)
arch/arm/mach-mvebu/coherency.c +3 -166
index db2f5bd..e568b2e 100644
@@ -28,7 +28,6 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/mbus.h>
-#include <linux/clk.h>
 #include <linux/pci.h>
 #include <asm/smp_plat.h>
 #include <asm/cacheflush.h>
@@ -77,157 +76,8 @@ int set_cpu_coherent(void)
 	return ll_enable_coherency();
 }
 
-/*
- * The below code implements the I/O coherency workaround on Armada
- * 375. This workaround consists in using the two channels of the
- * first XOR engine to trigger a XOR transaction that serves as the
- * I/O coherency barrier.
- */
-
-static void __iomem *xor_base, *xor_high_base;
-static dma_addr_t coherency_wa_buf_phys[CONFIG_NR_CPUS];
-static void *coherency_wa_buf[CONFIG_NR_CPUS];
-static bool coherency_wa_enabled;
-
-#define XOR_CONFIG(chan)            (0x10 + (chan * 4))
-#define XOR_ACTIVATION(chan)        (0x20 + (chan * 4))
-#define WINDOW_BAR_ENABLE(chan)     (0x240 + ((chan) << 2))
-#define WINDOW_BASE(w)              (0x250 + ((w) << 2))
-#define WINDOW_SIZE(w)              (0x270 + ((w) << 2))
-#define WINDOW_REMAP_HIGH(w)        (0x290 + ((w) << 2))
-#define WINDOW_OVERRIDE_CTRL(chan)  (0x2A0 + ((chan) << 2))
-#define XOR_DEST_POINTER(chan)      (0x2B0 + (chan * 4))
-#define XOR_BLOCK_SIZE(chan)        (0x2C0 + (chan * 4))
-#define XOR_INIT_VALUE_LOW           0x2E0
-#define XOR_INIT_VALUE_HIGH          0x2E4
-
-static inline void mvebu_hwcc_armada375_sync_io_barrier_wa(void)
-{
-	int idx = smp_processor_id();
-
-	/* Write '1' to the first word of the buffer */
-	writel(0x1, coherency_wa_buf[idx]);
-
-	/* Wait until the engine is idle */
-	while ((readl(xor_base + XOR_ACTIVATION(idx)) >> 4) & 0x3)
-		;
-
-	dmb();
-
-	/* Trigger channel */
-	writel(0x1, xor_base + XOR_ACTIVATION(idx));
-
-	/* Poll the data until it is cleared by the XOR transaction */
-	while (readl(coherency_wa_buf[idx]))
-		;
-}
-
-static void __init armada_375_coherency_init_wa(void)
-{
-	const struct mbus_dram_target_info *dram;
-	struct device_node *xor_node;
-	struct property *xor_status;
-	struct clk *xor_clk;
-	u32 win_enable = 0;
-	int i;
-
-	pr_warn("enabling coherency workaround for Armada 375 Z1, one XOR engine disabled\n");
-
-	/*
-	 * Since the workaround uses one XOR engine, we grab a
-	 * reference to its Device Tree node first.
-	 */
-	xor_node = of_find_compatible_node(NULL, NULL, "marvell,orion-xor");
-	BUG_ON(!xor_node);
-
-	/*
-	 * Then we mark it as disabled so that the real XOR driver
-	 * will not use it.
-	 */
-	xor_status = kzalloc(sizeof(struct property), GFP_KERNEL);
-	BUG_ON(!xor_status);
-
-	xor_status->value = kstrdup("disabled", GFP_KERNEL);
-	BUG_ON(!xor_status->value);
-
-	xor_status->length = 8;
-	xor_status->name = kstrdup("status", GFP_KERNEL);
-	BUG_ON(!xor_status->name);
-
-	of_update_property(xor_node, xor_status);
-
-	/*
-	 * And we remap the registers, get the clock, and do the
-	 * initial configuration of the XOR engine.
-	 */
-	xor_base = of_iomap(xor_node, 0);
-	xor_high_base = of_iomap(xor_node, 1);
-
-	xor_clk = of_clk_get_by_name(xor_node, NULL);
-	BUG_ON(!xor_clk);
-
-	clk_prepare_enable(xor_clk);
-
-	dram = mv_mbus_dram_info();
-
-	for (i = 0; i < 8; i++) {
-		writel(0, xor_base + WINDOW_BASE(i));
-		writel(0, xor_base + WINDOW_SIZE(i));
-		if (i < 4)
-			writel(0, xor_base + WINDOW_REMAP_HIGH(i));
-	}
-
-	for (i = 0; i < dram->num_cs; i++) {
-		const struct mbus_dram_window *cs = dram->cs + i;
-		writel((cs->base & 0xffff0000) |
-		       (cs->mbus_attr << 8) |
-		       dram->mbus_dram_target_id, xor_base + WINDOW_BASE(i));
-		writel((cs->size - 1) & 0xffff0000, xor_base + WINDOW_SIZE(i));
-
-		win_enable |= (1 << i);
-		win_enable |= 3 << (16 + (2 * i));
-	}
-
-	writel(win_enable, xor_base + WINDOW_BAR_ENABLE(0));
-	writel(win_enable, xor_base + WINDOW_BAR_ENABLE(1));
-	writel(0, xor_base + WINDOW_OVERRIDE_CTRL(0));
-	writel(0, xor_base + WINDOW_OVERRIDE_CTRL(1));
-
-	for (i = 0; i < CONFIG_NR_CPUS; i++) {
-		coherency_wa_buf[i] = kzalloc(PAGE_SIZE, GFP_KERNEL);
-		BUG_ON(!coherency_wa_buf[i]);
-
-		/*
-		 * We can't use the DMA mapping API, since we don't
-		 * have a valid 'struct device' pointer
-		 */
-		coherency_wa_buf_phys[i] =
-			virt_to_phys(coherency_wa_buf[i]);
-		BUG_ON(!coherency_wa_buf_phys[i]);
-
-		/*
-		 * Configure the XOR engine for memset operation, with
-		 * a 128 bytes block size
-		 */
-		writel(0x444, xor_base + XOR_CONFIG(i));
-		writel(128, xor_base + XOR_BLOCK_SIZE(i));
-		writel(coherency_wa_buf_phys[i],
-		       xor_base + XOR_DEST_POINTER(i));
-	}
-
-	writel(0x0, xor_base + XOR_INIT_VALUE_LOW);
-	writel(0x0, xor_base + XOR_INIT_VALUE_HIGH);
-
-	coherency_wa_enabled = true;
-}
-
 static inline void mvebu_hwcc_sync_io_barrier(void)
 {
-	if (coherency_wa_enabled) {
-		mvebu_hwcc_armada375_sync_io_barrier_wa();
-		return;
-	}
-
 	writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
 	while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET) & 0x1);
 }
@@ -421,22 +271,9 @@ int __init coherency_init(void)
 
 static int __init coherency_late_init(void)
 {
-	int type = coherency_type();
-
-	if (type == COHERENCY_FABRIC_TYPE_NONE)
-		return 0;
-
-	if (type == COHERENCY_FABRIC_TYPE_ARMADA_375) {
-		u32 dev, rev;
-
-		if (mvebu_get_soc_id(&dev, &rev) == 0 &&
-		    rev == ARMADA_375_Z1_REV)
-			armada_375_coherency_init_wa();
-	}
-
-	bus_register_notifier(&platform_bus_type,
-			      &mvebu_hwcc_nb);
-
+	if (coherency_available())
+		bus_register_notifier(&platform_bus_type,
+				      &mvebu_hwcc_nb);
 	return 0;
 }
 
Signature · 1 line
2.0.0
#9 lore raw

PATCH v3 5/5 ARM: mvebu: update comments in coherency.c

In reply to Thomas Petazzoni

The coherency.c top-level comment mentions that it supports the coherency fabric for Armada 370 and XP, but it also supports the coherency fabric on Armada 375 and 38x, so this commit updates the comment accordingly.

---
 arch/arm/mach-mvebu/coherency.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-mvebu/coherency.c +3 -2
index e568b2e..c18da36 100644
@@ -1,5 +1,6 @@
 /*
- * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
+ * Coherency fabric (Aurora) support for Armada 370, 375, 38x and XP
+ * platforms.
  *
  * Copyright (C) 2012 Marvell
  *
@@ -11,7 +12,7 @@
  * 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
+ * The Armada 370, 375, 38x and 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
Signature · 1 line
2.0.0
#10 lore raw

v3 cover ARM: mvebu: no I/O coherency on non-SMP and related updates

In reply to Thomas Petazzoni

Hello,

Quoted 2 lines · Thomas Petazzoni

This series makes a number of updates to the I/O coherency code of Marvell EBU platforms.

Jason, I forgot to mention that this series is based on top of the mvebu/fixes branch, since this branch contains the "ARM: mvebu: add missing of_node_put() call in coherency.c" commit.

Best regards,

Thomas

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

v3 cover ARM: mvebu: no I/O coherency on non-SMP and related updates

In reply to Thomas Petazzoni

Thomas,

Quoted 41 lines · Thomas Petazzoni

Hello,

This series makes a number of updates to the I/O coherency code of Marvell EBU platforms.

Changes since v2:

- Drop patch "ARM: mvebu: add missing of_node_put() call in coherency.c" since it was merged.

- Update "make the coherency_ll.S functions work with no coherency fabric" to use "reteq <reg>" instead of "moveq pc, <reg>", as suggested by Gr?gory Clement.

- Update the comment in "disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP" to give more details about what would be needed to get HW I/O coherency working on Armada 370, as suggested by Jason Cooper.

- Added Acked-by from Gr?gory Clement as appropriate.

- Added one patch to drop the Armada 375 Z1 workaround for I/O coherency, which removes a significant chunk of code from coherency.c.

- Added two patches doing minor cleanup/updates to coherency.c

Changes since v1:

- Rebased on top of v3.18-rc2.
- Added some Fixes:/Cc: tags on the last patch to get it merged into the stable tree, as it fixes a real DT reference count leak.

Best regards,

Thomas Petazzoni

Thomas Petazzoni (5):
ARM: mvebu: make the coherency_ll.S functions work with no coherency
fabric
ARM: mvebu: disable I/O coherency on non-SMP situations on Armada

Quoted 8 lines
    370/375/38x/XP

ARM: mvebu: remove unused register offset definition
ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency
ARM: mvebu: update comments in coherency.c

 arch/arm/mach-mvebu/coherency.c    | 220 ++++++-------------------------------
 arch/arm/mach-mvebu/coherency_ll.S |  21 +++-
 2 files changed, 55 insertions(+), 186 deletions(-)

Whole series applied to mvebu/soc with a dependency on mvebu/fixes.

thx,

Jason.