[PATCH 0/3] Misc fixes for Marvell EBU platforms

[PATCH 0/3] Misc fixes for Marvell EBU platforms

[Thomas Petazzoni]

Hello,

This small patch series carries a few fixes for Marvell EBU platforms:

 - The first one fixes HW I/O coherency deadlocks that can be easily
   reproduced with the CESA crypto engine.

 - The second one makes sure PCI I/O regions are mapped
   strongly-ordered. While this is technically a requirement for the
   HW I/O coherency to work reliably, PCI I/O regions are very rarely
   used and we have therefore never seen a problem caused by
   this. Therefore, I have not Cc'ed this patch to stable.

 - The third one fixes the MBus window attributes used to map the CESA
   SRAMs on Armada 385 Linksys platforms.

Thanks!

Thomas

Thomas Petazzoni (3):
  ARM: mvebu: fix HW I/O coherency related deadlocks
  ARM: mvebu: map PCI I/O regions strongly ordered
  ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385
    Linksys

 arch/arm/boot/dts/armada-385-linksys.dtsi |  4 ++--
 arch/arm/mach-mvebu/coherency.c           | 23 +++++++++--------------
 2 files changed, 11 insertions(+), 16 deletions(-)

-- 
2.7.4

[PATCH 1/3] ARM: mvebu: fix HW I/O coherency related deadlocks

[Thomas Petazzoni]

Until now, our understanding for HW I/O coherency to work on the
Cortex-A9 based Marvell SoC was that only the PCIe regions should be
mapped strongly-ordered. However, we were still encountering some
deadlocks, especially when testing the CESA crypto engine. After
checking with the HW designers, it was concluded that all the MMIO
registers should be mapped as strongly ordered for the HW I/O coherency
mechanism to work properly.

This fixes some easy to reproduce deadlocks with the CESA crypto engine
driver (dmcrypt on a sufficiently large disk partition).

Tested-by: Terry Stockert <stockert@inkblotadmirer.me>
Tested-by: Romain Perier <romain.perier@free-electrons.com>
Cc: Terry Stockert <stockert@inkblotadmirer.me>
Cc: Romain Perier <romain.perier@free-electrons.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c | 22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 7e989d6..474abff 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -162,22 +162,16 @@ exit:
 }
 
 /*
- * This ioremap hook is used on Armada 375/38x to ensure that PCIe
- * memory areas are mapped as MT_UNCACHED instead of MT_DEVICE. This
- * is needed as a workaround for a deadlock issue between the PCIe
- * interface and the cache controller.
+ * This ioremap hook is used on Armada 375/38x to ensure that all MMIO
+ * areas are mapped as MT_UNCACHED instead of MT_DEVICE. This is
+ * needed for the HW I/O coherency mechanism to work properly without
+ * deadlock.
  */
 static void __iomem *
-armada_pcie_wa_ioremap_caller(phys_addr_t phys_addr, size_t size,
-			      unsigned int mtype, void *caller)
+armada_wa_ioremap_caller(phys_addr_t phys_addr, size_t size,
+			 unsigned int mtype, void *caller)
 {
-	struct resource pcie_mem;
-
-	mvebu_mbus_get_pcie_mem_aperture(&pcie_mem);
-
-	if (pcie_mem.start <= phys_addr && (phys_addr + size) <= pcie_mem.end)
-		mtype = MT_UNCACHED;
-
+	mtype = MT_UNCACHED;
 	return __arm_ioremap_caller(phys_addr, size, mtype, caller);
 }
 
@@ -186,7 +180,7 @@ static void __init armada_375_380_coherency_init(struct device_node *np)
 	struct device_node *cache_dn;
 
 	coherency_cpu_base = of_iomap(np, 0);
-	arch_ioremap_caller = armada_pcie_wa_ioremap_caller;
+	arch_ioremap_caller = armada_wa_ioremap_caller;
 
 	/*
 	 * We should switch the PL310 to I/O coherency mode only if
-- 
2.7.4

[PATCH 1/3] ARM: mvebu: fix HW I/O coherency related deadlocks

[Gregory CLEMENT]

Hi Thomas,
 
 On jeu., juin 16 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Until now, our understanding for HW I/O coherency to work on the
> Cortex-A9 based Marvell SoC was that only the PCIe regions should be
> mapped strongly-ordered. However, we were still encountering some
> deadlocks, especially when testing the CESA crypto engine. After
> checking with the HW designers, it was concluded that all the MMIO
> registers should be mapped as strongly ordered for the HW I/O coherency
> mechanism to work properly.
>
> This fixes some easy to reproduce deadlocks with the CESA crypto engine
> driver (dmcrypt on a sufficiently large disk partition).
>
> Tested-by: Terry Stockert <stockert@inkblotadmirer.me>
> Tested-by: Romain Perier <romain.perier@free-electrons.com>
> Cc: Terry Stockert <stockert@inkblotadmirer.me>
> Cc: Romain Perier <romain.perier@free-electrons.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Applied on mvebu/fixes

Thanks,

Gregory


> ---
>  arch/arm/mach-mvebu/coherency.c | 22 ++++++++--------------
>  1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index 7e989d6..474abff 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -162,22 +162,16 @@ exit:
>  }
>  
>  /*
> - * This ioremap hook is used on Armada 375/38x to ensure that PCIe
> - * memory areas are mapped as MT_UNCACHED instead of MT_DEVICE. This
> - * is needed as a workaround for a deadlock issue between the PCIe
> - * interface and the cache controller.
> + * This ioremap hook is used on Armada 375/38x to ensure that all MMIO
> + * areas are mapped as MT_UNCACHED instead of MT_DEVICE. This is
> + * needed for the HW I/O coherency mechanism to work properly without
> + * deadlock.
>   */
>  static void __iomem *
> -armada_pcie_wa_ioremap_caller(phys_addr_t phys_addr, size_t size,
> -			      unsigned int mtype, void *caller)
> +armada_wa_ioremap_caller(phys_addr_t phys_addr, size_t size,
> +			 unsigned int mtype, void *caller)
>  {
> -	struct resource pcie_mem;
> -
> -	mvebu_mbus_get_pcie_mem_aperture(&pcie_mem);
> -
> -	if (pcie_mem.start <= phys_addr && (phys_addr + size) <= pcie_mem.end)
> -		mtype = MT_UNCACHED;
> -
> +	mtype = MT_UNCACHED;
>  	return __arm_ioremap_caller(phys_addr, size, mtype, caller);
>  }
>  
> @@ -186,7 +180,7 @@ static void __init armada_375_380_coherency_init(struct device_node *np)
>  	struct device_node *cache_dn;
>  
>  	coherency_cpu_base = of_iomap(np, 0);
> -	arch_ioremap_caller = armada_pcie_wa_ioremap_caller;
> +	arch_ioremap_caller = armada_wa_ioremap_caller;
>  
>  	/*
>  	 * We should switch the PL310 to I/O coherency mode only if
> -- 
> 2.7.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 2/3] ARM: mvebu: map PCI I/O regions strongly ordered

[Thomas Petazzoni]

In order for HW I/O coherency to work on Cortex-A9 based Marvell SoCs,
all MMIO registers must be mapped strongly ordered. In commit
1c8c3cf0b5239 ("ARM: 8060/1: mm: allow sub-architectures to override PCI
I/O memory type") we implemented a new function,
pci_ioremap_set_mem_type(), that allow sub-architecture code to override
the memory type used to map PCI I/O regions.

In the discussion around this patch series [1], Arnd Bergmann made the
comment that maybe all PCI I/O regions should be mapped
strongly-ordered, which would have made our proposal to add
pci_ioremap_set_mem_type() irrelevant. So, we submitted a patch [2] that
did what Arnd suggested.

However, Russell in the end merged our initial proposal to add
pci_ioremap_set_mem_type(), but it was never used anywhere. Further
discussion with Arnd and other folks on IRC lead to the conclusion that
in fact using strongly-ordered for all platforms was maybe not
desirable, and therefore, using pci_ioremap_set_mem_type() was the most
appropriate solution.

As a consequence, this commit finally adds the
pci_ioremap_set_mem_type() call in the mach-mvebu platform code, which
was originally part of our initial patch series [3] and is necessary for
the whole mechanism to work.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256565.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256755.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256563.html

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

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 474abff..e80f0dd 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -181,6 +181,7 @@ static void __init armada_375_380_coherency_init(struct device_node *np)
 
 	coherency_cpu_base = of_iomap(np, 0);
 	arch_ioremap_caller = armada_wa_ioremap_caller;
+	pci_ioremap_set_mem_type(MT_UNCACHED);
 
 	/*
 	 * We should switch the PL310 to I/O coherency mode only if
-- 
2.7.4

[PATCH 2/3] ARM: mvebu: map PCI I/O regions strongly ordered

[Gregory CLEMENT]

Hi Thomas,
 
 On jeu., juin 16 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> In order for HW I/O coherency to work on Cortex-A9 based Marvell SoCs,
> all MMIO registers must be mapped strongly ordered. In commit
> 1c8c3cf0b5239 ("ARM: 8060/1: mm: allow sub-architectures to override PCI
> I/O memory type") we implemented a new function,
> pci_ioremap_set_mem_type(), that allow sub-architecture code to override
> the memory type used to map PCI I/O regions.
>
> In the discussion around this patch series [1], Arnd Bergmann made the
> comment that maybe all PCI I/O regions should be mapped
> strongly-ordered, which would have made our proposal to add
> pci_ioremap_set_mem_type() irrelevant. So, we submitted a patch [2] that
> did what Arnd suggested.
>
> However, Russell in the end merged our initial proposal to add
> pci_ioremap_set_mem_type(), but it was never used anywhere. Further
> discussion with Arnd and other folks on IRC lead to the conclusion that
> in fact using strongly-ordered for all platforms was maybe not
> desirable, and therefore, using pci_ioremap_set_mem_type() was the most
> appropriate solution.
>
> As a consequence, this commit finally adds the
> pci_ioremap_set_mem_type() call in the mach-mvebu platform code, which
> was originally part of our initial patch series [3] and is necessary for
> the whole mechanism to work.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256565.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256755.html
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256563.html
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Applied on mvebu/fixes

Thanks,

Gregory

> ---
>  arch/arm/mach-mvebu/coherency.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index 474abff..e80f0dd 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -181,6 +181,7 @@ static void __init armada_375_380_coherency_init(struct device_node *np)
>  
>  	coherency_cpu_base = of_iomap(np, 0);
>  	arch_ioremap_caller = armada_wa_ioremap_caller;
> +	pci_ioremap_set_mem_type(MT_UNCACHED);
>  
>  	/*
>  	 * We should switch the PL310 to I/O coherency mode only if
> -- 
> 2.7.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 3/3] ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys

[Thomas Petazzoni]

When the support for the Marvell crypto engine was added in the Device
Tree of the various Armada 385 Device Tree files in commit
d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x
boards"), a typo was made in the MBus window attributes for the Armada
385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit
fixes this typo, which makes the CESA engines operational on Armada 385
Linksys boards.

Reported-by: Terry Stockert <stockert@inkblotadmirer.me>
Cc: Terry Stockert <stockert@inkblotadmirer.me>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: <stable@vger.kernel.org>
Fixes: d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-385-linksys.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 8450944..22f7a13 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -58,8 +58,8 @@
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
-			  MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
 
 		internal-regs {
 
-- 
2.7.4

[PATCH 3/3] ARM: dts: armada-38x: fix MBUS_ID for crypto SRAM on Armada 385 Linksys

[Gregory CLEMENT]

Hi Thomas,
 
 On jeu., juin 16 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> When the support for the Marvell crypto engine was added in the Device
> Tree of the various Armada 385 Device Tree files in commit
> d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x
> boards"), a typo was made in the MBus window attributes for the Armada
> 385 Linksys board: 0x09/0x05 are used instead of 0x19/0x15. This commit
> fixes this typo, which makes the CESA engines operational on Armada 385
> Linksys boards.
>
> Reported-by: Terry Stockert <stockert@inkblotadmirer.me>
> Cc: Terry Stockert <stockert@inkblotadmirer.me>
> Cc: Imre Kaloz <kaloz@openwrt.org>
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> Cc: <stable@vger.kernel.org>
> Fixes: d716f2e837ac6 ("ARM: mvebu: define crypto SRAM ranges for all armada-38x boards")
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Applied on mvebu/fixes

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-385-linksys.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index 8450944..22f7a13 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -58,8 +58,8 @@
>  	soc {
>  		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
>  			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> -			  MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
> -			  MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
> +			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
>  
>  		internal-regs {
>  
> -- 
> 2.7.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com