[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[Thomas Petazzoni]

Hello Jason,

Here are five patches making fixes and improvements to the Armada 375
support. They are related to the fact that we now have access to
Armada 375 A0 boards (however, Ezequiel still only has access to a Z1
platform, so we would like to keep Z1 support for now).

 * Patch 1 is really a fix. It fixes the thermal related quirk that
   was added by Ezequiel, to make sure it really works on A0 revision.

 * Patch 2 to 5 make the SMP and coherency workarounds conditional on
   the Armada 375 Z1. The condition on SMP is really mandatory to get
   SMP working on A0. For coherency, the WA could be used on A0, but
   it is useless and hurt performance.

The series is based on your mvebu/soc branch.

Changes since v1:

 * Made the dev and rev variable local to the appropriate if() block
   in PATCH 5.

 * Re-added the "Booting CPU" message in PATCH 4, which was
   mistakently removed in v1.

 * Extended the git commit message of PATCH 4 to explain why we're
   moving things from ->smp_prepare_cpus() to ->smp_boot_secondary().

 * Added Ezequiel's Acked-by on PATCH 1.

Thanks,

Thomas

Thomas Petazzoni (5):
  ARM: mvebu: fix thermal quirk SoC revision check
  ARM: mvebu: initialize mvebu-soc-id earlier
  ARM: mvebu: add Armada 375 A0 revision definition
  ARM: mvebu: conditionalize Armada 375 SMP workaround
  ARM: mvebu: conditionalize Armada 375 coherency workaround

 arch/arm/mach-mvebu/board-v7.c     |  2 +-
 arch/arm/mach-mvebu/coherency.c    | 10 ++++++++--
 arch/arm/mach-mvebu/mvebu-soc-id.c |  2 +-
 arch/arm/mach-mvebu/mvebu-soc-id.h |  1 +
 arch/arm/mach-mvebu/platsmp-a9.c   | 20 +++++++++++---------
 5 files changed, 22 insertions(+), 13 deletions(-)

-- 
1.9.2

[PATCH v2 1/5] ARM: mvebu: fix thermal quirk SoC revision check

[Thomas Petazzoni]

In commit 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add
thermal quirk for the Armada 375 DB board'), a check on the Armada SoC
revision was added to decide whether a quirk for the thermal device
should be applied or not.

However, the quirk implementation has a bug: it assumes
mvebu_get_soc_id() returns true on success, but it returns
0. Therefore, the condition:

  if (mvebu_get_soc_id(&dev, &rev) && rev > ARMADA_375_Z1_REV)

is always false (as long as mvebu-soc-id is properly initialized). As
a consequence, the quirk is always applied, even on A0 steppings, for
which the quirk should not be applied.

This was spotted by testing the thermal driver on Armada 375 A0, which
Ezequiel could not do since he does not have access to the A0 revision
of the SoC for the moment.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 54fe26a900bc528f3df1e4235cb6b9ca5c6d4dc2 ('ARM: mvebu: Add thermal quirk for the Armada 375 DB board')
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 arch/arm/mach-mvebu/board-v7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index bc0283f..01cfce6 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -120,7 +120,7 @@ static void __init thermal_quirk(void)
 	struct device_node *np;
 	u32 dev, rev;
 
-	if (mvebu_get_soc_id(&dev, &rev) && rev > ARMADA_375_Z1_REV)
+	if (mvebu_get_soc_id(&dev, &rev) == 0 && rev > ARMADA_375_Z1_REV)
 		return;
 
 	for_each_compatible_node(np, NULL, "marvell,armada375-thermal") {
-- 
1.9.2

[PATCH v2 2/5] ARM: mvebu: initialize mvebu-soc-id earlier

[Thomas Petazzoni]

Currently, the mvebu-soc-id logic is initialized through a
core_initcall(). However, we will soon need to know the SoC revision
before booting secondary CPUs, because a workaround affects Armada 375
Z1 steppings, but should not be applied on Armada 375 A0 steppings.

Unfortunately, core_initcall() are called way too late compared to the
SMP initialization. Therefore, the mvebu-soc-id initialization is move
to an early_initcall(), which is called before the SMP initialization.

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

diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.c b/arch/arm/mach-mvebu/mvebu-soc-id.c
index 874a750..e9119a9 100644
--- a/arch/arm/mach-mvebu/mvebu-soc-id.c
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -118,7 +118,7 @@ clk_err:
 
 	return ret;
 }
-core_initcall(mvebu_soc_id_init);
+early_initcall(mvebu_soc_id_init);
 
 static int __init mvebu_soc_device(void)
 {
-- 
1.9.2

[PATCH v2 3/5] ARM: mvebu: add Armada 375 A0 revision definition

[Thomas Petazzoni]

Now that we have access to Armada 375 A0 platforms, we can add the
corresponding revision definition in mvebu-soc-id.h.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/mvebu-soc-id.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.h b/arch/arm/mach-mvebu/mvebu-soc-id.h
index 294a443..c16bb68 100644
--- a/arch/arm/mach-mvebu/mvebu-soc-id.h
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.h
@@ -22,6 +22,7 @@
 
 /* Armada 375 */
 #define ARMADA_375_Z1_REV   0x0
+#define ARMADA_375_A0_REV   0x3
 
 #ifdef CONFIG_ARCH_MVEBU
 int mvebu_get_soc_id(u32 *dev, u32 *rev);
-- 
1.9.2

[PATCH v2 4/5] ARM: mvebu: conditionalize Armada 375 SMP workaround

[Thomas Petazzoni]

The Armada 375 SMP workaround only needs to be applied to the Z1
revision of the SoC. The A0 and later revisions have been fixed, and
no longer need this workaround.

Note that the initialization of the SMP workaround is delayed from
->smp_prepare_cpus() to ->smp_boot_secondary() because when
->smp_prepare_cpus() is called, the early initcalls have not be
called, so the mvebu-soc-id mechanism is not operational. Since the
workaround is anyway not needed before the secondary CPU is started,
we can delay its implementation until the ->smp_boot_secondary() call.

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

diff --git a/arch/arm/mach-mvebu/platsmp-a9.c b/arch/arm/mach-mvebu/platsmp-a9.c
index 04d0b18..96c2c59 100644
--- a/arch/arm/mach-mvebu/platsmp-a9.c
+++ b/arch/arm/mach-mvebu/platsmp-a9.c
@@ -20,6 +20,7 @@
 #include <asm/smp_scu.h>
 #include <asm/smp_plat.h>
 #include "common.h"
+#include "mvebu-soc-id.h"
 #include "pmsu.h"
 
 #define CRYPT0_ENG_ID   41
@@ -63,11 +64,19 @@ static int __cpuinit mvebu_cortex_a9_boot_secondary(unsigned int cpu,
 	 */
 	hw_cpu = cpu_logical_map(cpu);
 
-	if (of_machine_is_compatible("marvell,armada375"))
+	if (of_machine_is_compatible("marvell,armada375")) {
+		u32 dev, rev;
+
+		if (mvebu_get_soc_id(&dev, &rev) == 0 &&
+		    rev == ARMADA_375_Z1_REV)
+			armada_375_smp_cpu1_enable_wa();
+
 		mvebu_system_controller_set_cpu_boot_addr(mvebu_cortex_a9_secondary_startup);
-	else
+	}
+	else {
 		mvebu_pmsu_set_cpu_boot_addr(hw_cpu,
 					     mvebu_cortex_a9_secondary_startup);
+	}
 
 	smp_wmb();
 	ret = mvebu_cpu_reset_deassert(hw_cpu);
@@ -80,14 +89,7 @@ static int __cpuinit mvebu_cortex_a9_boot_secondary(unsigned int cpu,
 	return 0;
 }
 
-static void __init mvebu_cortex_a9_smp_prepare_cpus(unsigned int max_cpus)
-{
-	if (of_machine_is_compatible("marvell,armada375"))
-		armada_375_smp_cpu1_enable_wa();
-}
-
 static struct smp_operations mvebu_cortex_a9_smp_ops __initdata = {
-	.smp_prepare_cpus	= mvebu_cortex_a9_smp_prepare_cpus,
 	.smp_boot_secondary	= mvebu_cortex_a9_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
 	.cpu_die		= armada_xp_cpu_die,
-- 
1.9.2

[PATCH v2 5/5] ARM: mvebu: conditionalize Armada 375 coherency workaround

[Thomas Petazzoni]

The Armada 375 coherency workaround only needs to be applied to the Z1
revision of the SoC. The A0 and later revisions have been fixed, and
no longer need this workaround.

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

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 489edd1..1519532 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -33,6 +33,7 @@
 #include <asm/cacheflush.h>
 #include "armada-370-xp.h"
 #include "coherency.h"
+#include "mvebu-soc-id.h"
 
 unsigned long coherency_phys_base;
 static void __iomem *coherency_base;
@@ -365,8 +366,13 @@ static int __init coherency_late_init(void)
 	if (type == COHERENCY_FABRIC_TYPE_NONE)
 		return 0;
 
-	if (type == COHERENCY_FABRIC_TYPE_ARMADA_375)
-		armada_375_coherency_init_wa();
+	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_platform_nb);
-- 
1.9.2

[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[Jason Cooper]

On Mon, May 05, 2014 at 05:05:21PM +0200, Thomas Petazzoni wrote:
> Hello Jason,
> 
> Here are five patches making fixes and improvements to the Armada 375
> support. They are related to the fact that we now have access to
> Armada 375 A0 boards (however, Ezequiel still only has access to a Z1
> platform, so we would like to keep Z1 support for now).
> 
>  * Patch 1 is really a fix. It fixes the thermal related quirk that
>    was added by Ezequiel, to make sure it really works on A0 revision.
> 
>  * Patch 2 to 5 make the SMP and coherency workarounds conditional on
>    the Armada 375 Z1. The condition on SMP is really mandatory to get
>    SMP working on A0. For coherency, the WA could be used on A0, but
>    it is useless and hurt performance.
> 
> The series is based on your mvebu/soc branch.
> 
> Changes since v1:
> 
>  * Made the dev and rev variable local to the appropriate if() block
>    in PATCH 5.
> 
>  * Re-added the "Booting CPU" message in PATCH 4, which was
>    mistakently removed in v1.
> 
>  * Extended the git commit message of PATCH 4 to explain why we're
>    moving things from ->smp_prepare_cpus() to ->smp_boot_secondary().
> 
>  * Added Ezequiel's Acked-by on PATCH 1.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (5):
>   ARM: mvebu: fix thermal quirk SoC revision check
>   ARM: mvebu: initialize mvebu-soc-id earlier
>   ARM: mvebu: add Armada 375 A0 revision definition
>   ARM: mvebu: conditionalize Armada 375 SMP workaround
>   ARM: mvebu: conditionalize Armada 375 coherency workaround

hmmm, I didn't get #5...

thx,

Jason.

[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[Thomas Petazzoni]

Dear Jason Cooper,

On Mon, 5 May 2014 11:36:54 -0400, Jason Cooper wrote:

> > Thomas Petazzoni (5):
> >   ARM: mvebu: fix thermal quirk SoC revision check
> >   ARM: mvebu: initialize mvebu-soc-id earlier
> >   ARM: mvebu: add Armada 375 A0 revision definition
> >   ARM: mvebu: conditionalize Armada 375 SMP workaround
> >   ARM: mvebu: conditionalize Armada 375 coherency workaround
> 
> hmmm, I didn't get #5...

Weird because it made it through the LAKML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/253251.html

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[Jason Cooper]

On Mon, May 05, 2014 at 06:05:20PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Mon, 5 May 2014 11:36:54 -0400, Jason Cooper wrote:
> 
> > > Thomas Petazzoni (5):
> > >   ARM: mvebu: fix thermal quirk SoC revision check
> > >   ARM: mvebu: initialize mvebu-soc-id earlier
> > >   ARM: mvebu: add Armada 375 A0 revision definition
> > >   ARM: mvebu: conditionalize Armada 375 SMP workaround
> > >   ARM: mvebu: conditionalize Armada 375 coherency workaround
> > 
> > hmmm, I didn't get #5...
> 
> Weird because it made it through the LAKML:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/253251.html

yeah, it was probably a hiccup on my end.  Or more specifically, my
inbound remailer. :(

I have it now.

thx,

Jason.

[PATCH v2 0/5] ARM: mvebu: fixes and improvements for 375 support

[Jason Cooper]

On Mon, May 05, 2014 at 05:05:21PM +0200, Thomas Petazzoni wrote:
> Hello Jason,
> 
> Here are five patches making fixes and improvements to the Armada 375
> support. They are related to the fact that we now have access to
> Armada 375 A0 boards (however, Ezequiel still only has access to a Z1
> platform, so we would like to keep Z1 support for now).
> 
>  * Patch 1 is really a fix. It fixes the thermal related quirk that
>    was added by Ezequiel, to make sure it really works on A0 revision.
> 
>  * Patch 2 to 5 make the SMP and coherency workarounds conditional on
>    the Armada 375 Z1. The condition on SMP is really mandatory to get
>    SMP working on A0. For coherency, the WA could be used on A0, but
>    it is useless and hurt performance.
> 
> The series is based on your mvebu/soc branch.
> 
> Changes since v1:
> 
>  * Made the dev and rev variable local to the appropriate if() block
>    in PATCH 5.
> 
>  * Re-added the "Booting CPU" message in PATCH 4, which was
>    mistakently removed in v1.
> 
>  * Extended the git commit message of PATCH 4 to explain why we're
>    moving things from ->smp_prepare_cpus() to ->smp_boot_secondary().
> 
>  * Added Ezequiel's Acked-by on PATCH 1.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (5):
>   ARM: mvebu: fix thermal quirk SoC revision check
>   ARM: mvebu: initialize mvebu-soc-id earlier
>   ARM: mvebu: add Armada 375 A0 revision definition
>   ARM: mvebu: conditionalize Armada 375 SMP workaround
>   ARM: mvebu: conditionalize Armada 375 coherency workaround
> 
>  arch/arm/mach-mvebu/board-v7.c     |  2 +-
>  arch/arm/mach-mvebu/coherency.c    | 10 ++++++++--
>  arch/arm/mach-mvebu/mvebu-soc-id.c |  2 +-
>  arch/arm/mach-mvebu/mvebu-soc-id.h |  1 +
>  arch/arm/mach-mvebu/platsmp-a9.c   | 20 +++++++++++---------
>  5 files changed, 22 insertions(+), 13 deletions(-)

Whole series applied to mvebu/soc

I've not Cc'd stable for the first patch since the problem is only in
mvebu/soc atm. :)

thx,

Jason.