[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[Thomas Petazzoni]

Jason, Gregory, Andrew, Sebastian,

Here is a set of patches that make some changes to the mach-mvebu
coherency code, and the way the mvebu-mbus driver determines whether
hardware I/O coherency is enabled or not.

These changes are proposed in preparation to the introduction of the
support for more recent SOCs in mach-mvebu, which have a slightly
different coherency fabric (hence the need for different compatible
strings) and different constraints to be able to enable the I/O
coherency (not only the coherency fabric must be available, but the
kernel must be running in CONFIG_SMP).

Moreover, the mvebu-mbus driver was directly poking into the DT to
find whether a coherency fabric node was available or not, to
determine if I/O coherency is enabled or not. However, with the new
constraint that CONFIG_SMP must be enabled on some SOCs to get I/O
coherency, the solution of having mvebu-mbus directly poke into the DT
is not longer appropriate. This patch set therefore changes the
mvebu_mbus_dt_init() function call to take an additional boolean
argument telling whether the system is running in I/O coherent mode or
not.

I've for now marked those patches as RFC, to indicate that they are
clearly open for discussion. For example, I'm still wondering if I
should not introduce separate compatible strings
marvell,armada-370-coherency-fabric and
marvell,armada-xp-coherency-fabric for Armada 370 and Armada XP
respectively instead of using marvell,armada-370-coherency-fabric for
both. Our experience has shown that we often initially believe that a
given hardware unit is similar between SOCs, and then later discover
that there are in fact some slight differences, which should have
called for different compatible strings from the beginning.

Best regards,

Thomas

Thomas Petazzoni (6):
  ARM: mvebu: prepare coherency code to support more SOCs
  ARM: mvebu: add a coherency_available() call
  bus: mvebu: pass the coherency availability information at init time
  ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
  ARM: mvebu: update Armada 370/XP DT to use new coherency compatible
    string
  ARM: mvebu: update coherency fabric DT binding documentation

 .../devicetree/bindings/arm/coherency-fabric.txt   | 19 +++--
 arch/arm/boot/dts/armada-370-xp.dtsi               |  2 +-
 arch/arm/mach-kirkwood/board-dt.c                  |  2 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  2 +-
 arch/arm/mach-mvebu/coherency.c                    | 80 ++++++++++++++++------
 arch/arm/mach-mvebu/coherency.h                    |  1 +
 drivers/bus/mvebu-mbus.c                           | 11 +--
 include/linux/mbus.h                               |  2 +-
 8 files changed, 79 insertions(+), 40 deletions(-)

-- 
1.8.3.2

[PATCH RFCv1 1/6] ARM: mvebu: prepare coherency code to support more SOCs

[Thomas Petazzoni]

The code that handles the coherency fabric of Armada 370 and Armada XP
in arch/arm/mach-mvebu/coherency.c made the assumption that there was
only one type of coherency fabric. Unfortunately, it turns out that
upcoming SoCs have a slightly different coherency unit.

In preparation to the introduction of the coherency support for more
SoCs, this commit:

 * Adds a new "marvell,armada-370-coherency-fabric" compatible string,
   to indicate the Armada 370/XP variant of the coherency fabric. The
   existing compatible string "marvel,coherency-fabric" is preserved
   for compatibility reasons, and has the same behavior as
   the new "marvell,armada-370-coherency-fabric".

 * Introduces a data associated to the compatible string in the
   compatible string match table, so that the code can differantiate
   the variant of coherency unit being used.

 * Separates the coherency unit initialization code into its own
   function.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../devicetree/bindings/arm/coherency-fabric.txt   | 12 ++++-
 arch/arm/mach-mvebu/coherency.c                    | 53 ++++++++++++++++------
 2 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
index 17d8cd1..6bd8788 100644
--- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -4,7 +4,15 @@ Available on Marvell SOCs: Armada 370 and Armada XP
 
 Required properties:
 
-- compatible: "marvell,coherency-fabric"
+- compatible: the possible values are:
+
+ * "marvell,coherency-fabric", kept for backward compatibility reasons
+   only. To be used for the coherency fabric of the Armada 370 and
+   Armada XP. It is recommended to use
+   "marvell,armada-370-coherency-fabric" instead.
+
+ * "marvell,armada-370-coherency-fabric", for the Armada 370 and
+   Armada XP coherency fabric.
 
 - reg: Should contain coherency fabric registers location and
   length. First pair for the coherency fabric registers, second pair
@@ -13,7 +21,7 @@ Required properties:
 Example:
 
 coherency-fabric at d0020200 {
-	compatible = "marvell,coherency-fabric";
+	compatible = "marvell,armada-370-coherency-fabric";
 	reg = <0xd0020200 0xb0>,
 		<0xd0021810 0x1c>;
 
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 58adf2f..a8209ae 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -37,8 +37,20 @@ static void __iomem *coherency_cpu_base;
 
 #define IO_SYNC_BARRIER_CTL_OFFSET		   0x0
 
+enum {
+	COHERENCY_FABRIC_TYPE_ARMADA_370_XP,
+};
+
+/*
+ * The "marvell,coherency-fabric" compatible string is kept for
+ * backward compatibility reasons, and is equivalent to
+ * "marvell,armada-370-coherency-fabric".
+ */
 static struct of_device_id of_coherency_table[] = {
-	{.compatible = "marvell,coherency-fabric"},
+	{.compatible = "marvell,coherency-fabric",
+	 .data = (void *) COHERENCY_FABRIC_TYPE_ARMADA_370_XP },
+	{.compatible = "marvell,armada-370-coherency-fabric",
+	 .data = (void *) COHERENCY_FABRIC_TYPE_ARMADA_370_XP },
 	{ /* end of list */ },
 };
 
@@ -120,26 +132,39 @@ static struct notifier_block mvebu_hwcc_platform_nb = {
 	.notifier_call = mvebu_hwcc_platform_notifier,
 };
 
+static void __init armada_370_coherency_init(struct device_node *np)
+{
+	struct resource res;
+	of_address_to_resource(np, 0, &res);
+	coherency_phys_base = res.start;
+	/*
+	 * Ensure secondary CPUs will see the updated value,
+	 * which they read before they join the coherency
+	 * fabric, and therefore before they are coherent with
+	 * the boot CPU cache.
+	 */
+	sync_cache_w(&coherency_phys_base);
+	coherency_base = of_iomap(np, 0);
+	coherency_cpu_base = of_iomap(np, 1);
+	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+}
+
 int __init coherency_init(void)
 {
 	struct device_node *np;
 
 	np = of_find_matching_node(NULL, of_coherency_table);
 	if (np) {
-		struct resource res;
+		const struct of_device_id *match =
+			of_match_node(of_coherency_table, np);
+		int type;
+
+		type = (int) match->data;
 		pr_info("Initializing Coherency fabric\n");
-		of_address_to_resource(np, 0, &res);
-		coherency_phys_base = res.start;
-		/*
-		 * Ensure secondary CPUs will see the updated value,
-		 * which they read before they join the coherency
-		 * fabric, and therefore before they are coherent with
-		 * the boot CPU cache.
-		 */
-		sync_cache_w(&coherency_phys_base);
-		coherency_base = of_iomap(np, 0);
-		coherency_cpu_base = of_iomap(np, 1);
-		set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+
+		if (type == COHERENCY_FABRIC_TYPE_ARMADA_370_XP)
+			armada_370_coherency_init(np);
+
 		of_node_put(np);
 	}
 
-- 
1.8.3.2

[PATCH RFCv1 2/6] ARM: mvebu: add a coherency_available() call

[Thomas Petazzoni]

This commit extends the coherency fabric code to provide a
coherency_available()function that the SoC code can call to be told
whether coherency support is available or not. On Armada 370/XP,
coherency support is available as soon as the relevant DT node is
present. On some upcoming SoCs, the DT node needs to be present *and*
the system running with CONFIG_SMP enabled.

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

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index a8209ae..70db4e9 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -38,6 +38,7 @@ static void __iomem *coherency_cpu_base;
 #define IO_SYNC_BARRIER_CTL_OFFSET		   0x0
 
 enum {
+	COHERENCY_FABRIC_TYPE_NONE,
 	COHERENCY_FABRIC_TYPE_ARMADA_370_XP,
 };
 
@@ -149,7 +150,7 @@ static void __init armada_370_coherency_init(struct device_node *np)
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
 }
 
-int __init coherency_init(void)
+static int coherency_type(void)
 {
 	struct device_node *np;
 
@@ -160,27 +161,42 @@ int __init coherency_init(void)
 		int type;
 
 		type = (int) match->data;
+
 		pr_info("Initializing Coherency fabric\n");
 
+		/* Armada 370/XP coherency works in both UP and SMP */
 		if (type == COHERENCY_FABRIC_TYPE_ARMADA_370_XP)
-			armada_370_coherency_init(np);
+			return type;
 
 		of_node_put(np);
 	}
 
-	return 0;
+	return COHERENCY_FABRIC_TYPE_NONE;
 }
 
-static int __init coherency_late_init(void)
+int coherency_available(void)
 {
+	return coherency_type() != COHERENCY_FABRIC_TYPE_NONE;
+}
+
+int __init coherency_init(void)
+{
+	int type = coherency_type();
 	struct device_node *np;
 
 	np = of_find_matching_node(NULL, of_coherency_table);
-	if (np) {
+
+	if (type == COHERENCY_FABRIC_TYPE_ARMADA_370_XP)
+		armada_370_coherency_init(np);
+
+	return 0;
+}
+
+static int __init coherency_late_init(void)
+{
+	if (coherency_available())
 		bus_register_notifier(&platform_bus_type,
 				      &mvebu_hwcc_platform_nb);
-		of_node_put(np);
-	}
 	return 0;
 }
 
diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
index df33ad8..2a05b6e 100644
--- a/arch/arm/mach-mvebu/coherency.h
+++ b/arch/arm/mach-mvebu/coherency.h
@@ -16,5 +16,6 @@
 
 int set_cpu_coherent(int cpu_id, int smp_group_id);
 int coherency_init(void);
+int coherency_available(void);
 
 #endif	/* __MACH_370_XP_COHERENCY_H */
-- 
1.8.3.2

[PATCH RFCv1 3/6] bus: mvebu: pass the coherency availability information at init time

[Thomas Petazzoni]

Until now, the mvebu-mbus was guessing by itself whether hardware I/O
coherency was available or not by poking into the Device Tree to see
if the coherency fabric Device Tree node was present or not.

However, on some upcoming SoCs, the presence or absence of the
coherency fabric DT node isn't sufficient: in CONFIG_SMP, the
coherency can be enabled, but not in !CONFIG_SMP.

In order to clean this up, the mvebu_mbus_dt_init() function is
extended to get a boolean argument telling whether coherency is
enabled or not. Therefore, the logic to decide whether coherency is
available or not now belongs to the core SoC code instead of the
mvebu-mbus driver itself, which is much better.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-kirkwood/board-dt.c   |  2 +-
 arch/arm/mach-mvebu/armada-370-xp.c |  2 +-
 drivers/bus/mvebu-mbus.c            | 11 +++--------
 include/linux/mbus.h                |  2 +-
 4 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 9caa4fe..ba0f1ca 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -150,7 +150,7 @@ static void __init kirkwood_dt_init(void)
 	 */
 	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
 
-	BUG_ON(mvebu_mbus_dt_init());
+	BUG_ON(mvebu_mbus_dt_init(false));
 
 	kirkwood_l2_init();
 
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index e2acff9..b407525 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -39,7 +39,7 @@ static void __init armada_370_xp_timer_and_clk_init(void)
 	of_clk_init(NULL);
 	clocksource_of_init();
 	coherency_init();
-	BUG_ON(mvebu_mbus_dt_init());
+	BUG_ON(mvebu_mbus_dt_init(coherency_available()));
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 2394e97..16d11cf 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -700,7 +700,6 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 					 phys_addr_t sdramwins_phys_base,
 					 size_t sdramwins_size)
 {
-	struct device_node *np;
 	int win;
 
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
@@ -713,12 +712,6 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 		return -ENOMEM;
 	}
 
-	np = of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric");
-	if (np) {
-		mbus->hw_io_coherency = 1;
-		of_node_put(np);
-	}
-
 	for (win = 0; win < mbus->soc->num_wins; win++)
 		mvebu_mbus_disable_window(mbus, win);
 
@@ -888,7 +881,7 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 	}
 }
 
-int __init mvebu_mbus_dt_init(void)
+int __init mvebu_mbus_dt_init(bool is_coherent)
 {
 	struct resource mbuswins_res, sdramwins_res;
 	struct device_node *np, *controller;
@@ -927,6 +920,8 @@ int __init mvebu_mbus_dt_init(void)
 		return -EINVAL;
 	}
 
+	mbus_state.hw_io_coherency = is_coherent;
+
 	/* Get optional pcie-{mem,io}-aperture properties */
 	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
 					  &mbus_state.pcie_io_aperture);
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 345b8c5..550c88f 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -73,6 +73,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
-int mvebu_mbus_dt_init(void);
+int mvebu_mbus_dt_init(bool is_coherent);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.3.2

[PATCH RFCv1 4/6] ARM: mvebu: use of_find_matching_node_and_match() in coherency.c

[Thomas Petazzoni]

In the mach-mvebu coherency code, instead of using
of_find_matching_node() and then of_match_node(), directly use the
of_find_matching_node_and_match() which does both at once.

We take this opportunity to also simplify the initialization of the
"type" variable.

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

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 70db4e9..2eb3243 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -153,14 +153,11 @@ static void __init armada_370_coherency_init(struct device_node *np)
 static int coherency_type(void)
 {
 	struct device_node *np;
+	const struct of_device_id *match;
 
-	np = of_find_matching_node(NULL, of_coherency_table);
+	np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
 	if (np) {
-		const struct of_device_id *match =
-			of_match_node(of_coherency_table, np);
-		int type;
-
-		type = (int) match->data;
+		int type = (int) match->data;
 
 		pr_info("Initializing Coherency fabric\n");
 
-- 
1.8.3.2

[PATCH RFCv1 5/6] ARM: mvebu: update Armada 370/XP DT to use new coherency compatible string

[Thomas Petazzoni]

Update the common Armada 370 and Armada XP Device Tree files to use
the new compatible string for the coherency fabric.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 7f10f62..c32f522 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -117,7 +117,7 @@
 			};
 
 			coherency-fabric at 20200 {
-				compatible = "marvell,coherency-fabric";
+				compatible = "marvell,armada-370-coherency-fabric";
 				reg = <0x20200 0xb0>, <0x21010 0x1c>;
 			};
 
-- 
1.8.3.2

[PATCH RFCv1 6/6] ARM: mvebu: update coherency fabric DT binding documentation

[Thomas Petazzoni]

Update the Marvell coherency fabric DT binding documentation to
provide an example that uses valid register addresses for the second
register pair. Take this opportunity to change the example to have
only register offsets from the internal register base address instead
of absolute addresses, as is now done in the real DT files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 Documentation/devicetree/bindings/arm/coherency-fabric.txt | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
index 6bd8788..857de26 100644
--- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -20,10 +20,7 @@ Required properties:
 
 Example:
 
-coherency-fabric at d0020200 {
+coherency-fabric at 20200 {
 	compatible = "marvell,armada-370-coherency-fabric";
-	reg = <0xd0020200 0xb0>,
-		<0xd0021810 0x1c>;
-
+	reg = <0x20200 0xb0>, <0x21010 0x1c>;
 };
-
-- 
1.8.3.2

[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[Jason Cooper]

Thomas,

On Thu, Dec 26, 2013 at 03:12:50PM +0100, Thomas Petazzoni wrote:
> Jason, Gregory, Andrew, Sebastian,
> 
> Here is a set of patches that make some changes to the mach-mvebu
> coherency code, and the way the mvebu-mbus driver determines whether
> hardware I/O coherency is enabled or not.
> 
> These changes are proposed in preparation to the introduction of the
> support for more recent SOCs in mach-mvebu, which have a slightly
> different coherency fabric (hence the need for different compatible
> strings) and different constraints to be able to enable the I/O
> coherency (not only the coherency fabric must be available, but the
> kernel must be running in CONFIG_SMP).
> 
> Moreover, the mvebu-mbus driver was directly poking into the DT to
> find whether a coherency fabric node was available or not, to
> determine if I/O coherency is enabled or not. However, with the new
> constraint that CONFIG_SMP must be enabled on some SOCs to get I/O
> coherency, the solution of having mvebu-mbus directly poke into the DT
> is not longer appropriate. This patch set therefore changes the
> mvebu_mbus_dt_init() function call to take an additional boolean
> argument telling whether the system is running in I/O coherent mode or
> not.
> 
> I've for now marked those patches as RFC, to indicate that they are
> clearly open for discussion. For example, I'm still wondering if I
> should not introduce separate compatible strings
> marvell,armada-370-coherency-fabric and
> marvell,armada-xp-coherency-fabric for Armada 370 and Armada XP
> respectively instead of using marvell,armada-370-coherency-fabric for
> both. Our experience has shown that we often initially believe that a
> given hardware unit is similar between SOCs, and then later discover
> that there are in fact some slight differences, which should have
> called for different compatible strings from the beginning.
> 
> Best regards,
> 
> Thomas
> 
> Thomas Petazzoni (6):
>   ARM: mvebu: prepare coherency code to support more SOCs
>   ARM: mvebu: add a coherency_available() call
>   bus: mvebu: pass the coherency availability information at init time
>   ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
>   ARM: mvebu: update Armada 370/XP DT to use new coherency compatible
>     string
>   ARM: mvebu: update coherency fabric DT binding documentation
> 
>  .../devicetree/bindings/arm/coherency-fabric.txt   | 19 +++--
>  arch/arm/boot/dts/armada-370-xp.dtsi               |  2 +-
>  arch/arm/mach-kirkwood/board-dt.c                  |  2 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |  2 +-
>  arch/arm/mach-mvebu/coherency.c                    | 80 ++++++++++++++++------
>  arch/arm/mach-mvebu/coherency.h                    |  1 +
>  drivers/bus/mvebu-mbus.c                           | 11 +--
>  include/linux/mbus.h                               |  2 +-
>  8 files changed, 79 insertions(+), 40 deletions(-)

How is this different than the RFC v1 I just looked over?

thx,

Jason.

[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[Jason Cooper]

On Fri, Dec 27, 2013 at 12:32:13PM -0500, Jason Cooper wrote:
> Thomas,
> 
> On Thu, Dec 26, 2013 at 03:12:50PM +0100, Thomas Petazzoni wrote:
> > Jason, Gregory, Andrew, Sebastian,
> > 
> > Here is a set of patches that make some changes to the mach-mvebu
> > coherency code, and the way the mvebu-mbus driver determines whether
> > hardware I/O coherency is enabled or not.
> > 
> > These changes are proposed in preparation to the introduction of the
> > support for more recent SOCs in mach-mvebu, which have a slightly
> > different coherency fabric (hence the need for different compatible
> > strings) and different constraints to be able to enable the I/O
> > coherency (not only the coherency fabric must be available, but the
> > kernel must be running in CONFIG_SMP).
> > 
> > Moreover, the mvebu-mbus driver was directly poking into the DT to
> > find whether a coherency fabric node was available or not, to
> > determine if I/O coherency is enabled or not. However, with the new
> > constraint that CONFIG_SMP must be enabled on some SOCs to get I/O
> > coherency, the solution of having mvebu-mbus directly poke into the DT
> > is not longer appropriate. This patch set therefore changes the
> > mvebu_mbus_dt_init() function call to take an additional boolean
> > argument telling whether the system is running in I/O coherent mode or
> > not.
> > 
> > I've for now marked those patches as RFC, to indicate that they are
> > clearly open for discussion. For example, I'm still wondering if I
> > should not introduce separate compatible strings
> > marvell,armada-370-coherency-fabric and
> > marvell,armada-xp-coherency-fabric for Armada 370 and Armada XP
> > respectively instead of using marvell,armada-370-coherency-fabric for
> > both. Our experience has shown that we often initially believe that a
> > given hardware unit is similar between SOCs, and then later discover
> > that there are in fact some slight differences, which should have
> > called for different compatible strings from the beginning.
> > 
> > Best regards,
> > 
> > Thomas
> > 
> > Thomas Petazzoni (6):
> >   ARM: mvebu: prepare coherency code to support more SOCs
> >   ARM: mvebu: add a coherency_available() call
> >   bus: mvebu: pass the coherency availability information at init time
> >   ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
> >   ARM: mvebu: update Armada 370/XP DT to use new coherency compatible
> >     string
> >   ARM: mvebu: update coherency fabric DT binding documentation
> > 
> >  .../devicetree/bindings/arm/coherency-fabric.txt   | 19 +++--
> >  arch/arm/boot/dts/armada-370-xp.dtsi               |  2 +-
> >  arch/arm/mach-kirkwood/board-dt.c                  |  2 +-
> >  arch/arm/mach-mvebu/armada-370-xp.c                |  2 +-
> >  arch/arm/mach-mvebu/coherency.c                    | 80 ++++++++++++++++------
> >  arch/arm/mach-mvebu/coherency.h                    |  1 +
> >  drivers/bus/mvebu-mbus.c                           | 11 +--
> >  include/linux/mbus.h                               |  2 +-
> >  8 files changed, 79 insertions(+), 40 deletions(-)
> 
> How is this different than the RFC v1 I just looked over?

And now that I've made it past my inbox and to the list emails, it's
rather obvious. ;-)

thx,

Jason.

[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[Jason Cooper]

Thomas,

On Thu, Dec 26, 2013 at 03:12:50PM +0100, Thomas Petazzoni wrote:
> Jason, Gregory, Andrew, Sebastian,
> 
> Here is a set of patches that make some changes to the mach-mvebu
> coherency code, and the way the mvebu-mbus driver determines whether
> hardware I/O coherency is enabled or not.
> 
> These changes are proposed in preparation to the introduction of the
> support for more recent SOCs in mach-mvebu, which have a slightly
> different coherency fabric (hence the need for different compatible
> strings) and different constraints to be able to enable the I/O
> coherency (not only the coherency fabric must be available, but the
> kernel must be running in CONFIG_SMP).
> 
> Moreover, the mvebu-mbus driver was directly poking into the DT to
> find whether a coherency fabric node was available or not, to
> determine if I/O coherency is enabled or not. However, with the new
> constraint that CONFIG_SMP must be enabled on some SOCs to get I/O
> coherency, the solution of having mvebu-mbus directly poke into the DT
> is not longer appropriate. This patch set therefore changes the
> mvebu_mbus_dt_init() function call to take an additional boolean
> argument telling whether the system is running in I/O coherent mode or
> not.
> 
> I've for now marked those patches as RFC, to indicate that they are
> clearly open for discussion. For example, I'm still wondering if I
> should not introduce separate compatible strings
> marvell,armada-370-coherency-fabric and
> marvell,armada-xp-coherency-fabric for Armada 370 and Armada XP
> respectively instead of using marvell,armada-370-coherency-fabric for
> both. Our experience has shown that we often initially believe that a
> given hardware unit is similar between SOCs, and then later discover
> that there are in fact some slight differences, which should have
> called for different compatible strings from the beginning.
> 
> Best regards,
> 
> Thomas
> 
> Thomas Petazzoni (6):
>   ARM: mvebu: prepare coherency code to support more SOCs
>   ARM: mvebu: add a coherency_available() call
>   bus: mvebu: pass the coherency availability information at init time
>   ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
>   ARM: mvebu: update Armada 370/XP DT to use new coherency compatible
>     string
>   ARM: mvebu: update coherency fabric DT binding documentation
> 
>  .../devicetree/bindings/arm/coherency-fabric.txt   | 19 +++--
>  arch/arm/boot/dts/armada-370-xp.dtsi               |  2 +-
>  arch/arm/mach-kirkwood/board-dt.c                  |  2 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |  2 +-
>  arch/arm/mach-mvebu/coherency.c                    | 80 ++++++++++++++++------
>  arch/arm/mach-mvebu/coherency.h                    |  1 +
>  drivers/bus/mvebu-mbus.c                           | 11 +--
>  include/linux/mbus.h                               |  2 +-
>  8 files changed, 79 insertions(+), 40 deletions(-)

How is this different than the RFC v1 I just looked over?

thx,

Jason.

[PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements

[Jason Cooper]

All,

resending to include the MLs

On Thu, Dec 26, 2013 at 05:29:31PM +0100, Andrew Lunn wrote:
> On Thu, Dec 26, 2013 at 05:13:02PM +0100, Thomas Petazzoni wrote:
> > Dear Andrew Lunn,
> > 
> > On Thu, 26 Dec 2013 17:08:31 +0100, Andrew Lunn wrote:
> > 
> > > In the .dtsi file i would suggest multiple compatibilities from the
> > > most specific to the most general. So listing:
> > > marvell,armada-370-coherency-fabric,
> > > marvell,armada-370-xp-coherency-fabric,
> > > 
> > > gives you the most forward/backward compatibility, as you discover
> > > more about the hardware.
> > 
> > True, that's another possibility. Though it's unclear if a compatible
> > string such as "marvell,armada-370-xp-coherency-fabric" makes sense. If
> > you create such a compatible string, and then later discover than 370
> > and XP cannot be handled in a same way, then why have a "shared"
> > compatible string?
> 
> Well presumably, if you need to split it further, it is somehow
> broken, or at least not optimal. Anybody who cannot update there DT
> blob keeps with the current somehow broken/non-optimal behavior, but
> those who can upgrade there DT blob get better behavior.
> 
> More compatible strings helps with backward compatibility for old DT
> blobs.

Please, let's not over-think this.  Right now, are there _any_
capability differences we're aware of between the two?  If not, then we
should use marvell,armada-370-xp-coherency-fabric.  *after* we discover
an incompatible difference, then we add
marvell,armada-370-coherency-fabric.  The driver, if it sees the new
compatible string, will use the new feature.  If it doesn't, it will
default to the old behavior as it was under
marvell,armada-370-xp-coherency-fabric.

Let's not get ahead of ourselves guessing towards the 'perfect' DT
binding.

thx,

Jason.