[PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates

[PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates

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

-- 
2.0.0

[PATCHv3 1/5] ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric

[Thomas Petazzoni]

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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.8+
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency_ll.S | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index f5d881b..8b2fbc8 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -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
-- 
2.0.0

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

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O Coherency support")
Cc: <stable@vger.kernel.org> # v3.8+
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c | 44 ++++++++++++++++++++++++++++-------------
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 044b511..c31f4c0 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -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)
-- 
2.0.0

[PATCHv3 3/5] ARM: mvebu: remove unused register offset definition

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index c31f4c0..db2f5bd 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -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 {
-- 
2.0.0

[PATCHv3 4/5] ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c | 169 +---------------------------------------
 1 file changed, 3 insertions(+), 166 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index db2f5bd..e568b2e 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -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;
 }
 
-- 
2.0.0

[PATCHv3 5/5] ARM: mvebu: update comments in coherency.c

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index e568b2e..c18da36 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -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
-- 
2.0.0

[PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates

[Thomas Petazzoni]

Hello,

On Thu, 13 Nov 2014 10:38:55 +0100, Thomas Petazzoni wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Arnd Bergmann]

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).
> 
> In the process, it simplifies the implementation of the
> coherency_type() function, and adds a missing call to of_node_put().
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O Coherency support")
> Cc: <stable@vger.kernel.org> # v3.8+
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> 

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

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

[Thomas Petazzoni]

Dear Arnd Bergmann,

On Thu, 13 Nov 2014 11:10:07 +0100, Arnd Bergmann wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Arnd Bergmann]

On Thursday 13 November 2014 11:17:30 Thomas Petazzoni wrote:
> On Thu, 13 Nov 2014 11:10:07 +0100, Arnd Bergmann wrote:
> 
> > 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?

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

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

[Thomas Petazzoni]

Dear Arnd Bergmann,

On Thu, 13 Nov 2014 11:53:19 +0100, Arnd Bergmann wrote:

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

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCHv3 0/5] ARM: mvebu: no I/O coherency on non-SMP and related updates

[Jason Cooper]

Thomas,

On Thu, Nov 13, 2014 at 10:38:55AM +0100, Thomas Petazzoni wrote:
> 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(-)

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

thx,

Jason.