[GIT PULL 3.9] Various fixes for Marvell EBU platforms

[GIT PULL 3.9] Various fixes for Marvell EBU platforms

[Thomas Petazzoni]

Jason, Andrew, Greg,

Here are four fixes for Marvell EBU platforms. The first fix is very
important, without it, all Armada 370/XP platforms are broken. The
second fix is important as well because it makes the Armada XP GP
platform actually usable (without it, the platform boots, but no
network, no XOR, almost nothing works). The two other patches are
minor DT fixes.

Thanks.

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git at github.com:MISL-EBU-System-SW/mainline-public.git tags/marvell-3.9-fixes-tag

for you to fetch changes up to 6e025ae424c90febf2d0ad4368f0e5cba8b46f77:

  arm: mach-orion5x: fix typo in compatible string of a .dts file (2013-03-06 10:32:59 +0100)

----------------------------------------------------------------
Various small fixes for Marvell EBU platforms, intended for 3.9.

----------------------------------------------------------------
Heikki Krogerus (1):
      arm: mvebu: Reduce reg-io-width with UARTs

Thomas Petazzoni (3):
      arm: plat-orion: fix address decoding when > 4GB is used
      arm: mvebu: fix address-cells in mpic DT node
      arm: mach-orion5x: fix typo in compatible string of a .dts file

 arch/arm/boot/dts/armada-370-xp.dtsi               |    5 ++---
 arch/arm/boot/dts/armada-xp.dtsi                   |    4 ++--
 .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |    2 +-
 arch/arm/plat-orion/addr-map.c                     |    7 +++++--
 4 files changed, 10 insertions(+), 8 deletions(-)

[PATCH 1/4] arm: mvebu: Reduce reg-io-width with UARTs

[Thomas Petazzoni]

From: Heikki Krogerus <heikki.krogerus@linux.intel.com>

Setting the reg-io-width to 1 byte represents more accurate
description of the HW.

This will fix an issue where UART driver causes kernel
panic during bootup. Gregory CLEMENT traced the issue to
autoconfig() in 8250.c, where the existence of FIFO is
checked from UART_IIR register. The register is now read as
32-bit value as the reg-io-width is set to 4-bytes. The
retuned value seems to contain bogus data for bits 31:8,
causing the issue.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |    4 ++--
 arch/arm/boot/dts/armada-xp.dtsi     |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 6f1acc7..99afca4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -54,7 +54,7 @@
 				reg = <0xd0012000 0x100>;
 				reg-shift = <2>;
 				interrupts = <41>;
-				reg-io-width = <4>;
+				reg-io-width = <1>;
 				status = "disabled";
 		};
 		serial at d0012100 {
@@ -62,7 +62,7 @@
 				reg = <0xd0012100 0x100>;
 				reg-shift = <2>;
 				interrupts = <42>;
-				reg-io-width = <4>;
+				reg-io-width = <1>;
 				status = "disabled";
 		};
 
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 1443949..ca00d83 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -46,7 +46,7 @@
 				reg = <0xd0012200 0x100>;
 				reg-shift = <2>;
 				interrupts = <43>;
-				reg-io-width = <4>;
+				reg-io-width = <1>;
 				status = "disabled";
 		};
 		serial at d0012300 {
@@ -54,7 +54,7 @@
 				reg = <0xd0012300 0x100>;
 				reg-shift = <2>;
 				interrupts = <44>;
-				reg-io-width = <4>;
+				reg-io-width = <1>;
 				status = "disabled";
 		};
 
-- 
1.7.9.5

[PATCH 2/4] arm: plat-orion: fix address decoding when > 4GB is used

[Thomas Petazzoni]

During the system initialization, the orion_setup_cpu_mbus_target()
function reads the SDRAM address decoding registers to find out how
many chip-selects of SDRAM have been enabled, and builds a small array
with one entry per chip-select. This array is then used by device
drivers (XOR, Ethernet, etc.) to configure their own address decoding
windows to the SDRAM.

However, devices can only access the first 32 bits of the physical
memory. Even though LPAE is not supported for now, some Marvell boards
are now showing up with 8 GB of RAM, configured using two SDRAM
address decoding windows: the first covering the first 4 GB, the
second covering the last 4 GB. The array built by
orion_setup_cpu_mbus_target() has therefore two entries, and device
drivers try to set up two address decoding windows to the
SDRAM. However, in the device registers for the address decoding, the
base address is only 32 bits, so those two windows overlap each other,
and the devices do not work at all.

This patch makes sure that the array built by
orion_setup_cpu_mbus_target() only contains the SDRAM decoding windows
that correspond to the first 4 GB of the memory. To do that, it
ignores the SDRAM decoding windows for which the 4 low-order bits are
not zero (the 4 low-order bits of the base register are used to store
bits 32:35 of the base address, so they actually indicate whether the
base address is above 4 GB).

This patch allows the newly introduced armada-xp-gp board to properly
operate when it is mounted with more than 4 GB of RAM. Without that,
all devices doing DMA (for example XOR and Ethernet) do not work at
all.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a slightly updated version compared to the one sent on
February 27th on LAKML. The earlier version was looking at the three
low-order bits, but in fact there are four low-order bits to encode
the high bits of the base address. So the mask was changed from 0x7 to
0xF.

Since I've changed the patch, I haven't kept the Tested-by from Lior
Amsalem, Gr?gory Clement and Ezequiel Garcia.
---
 arch/arm/plat-orion/addr-map.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/plat-orion/addr-map.c
index febe386..807ac8e 100644
--- a/arch/arm/plat-orion/addr-map.c
+++ b/arch/arm/plat-orion/addr-map.c
@@ -157,9 +157,12 @@ void __init orion_setup_cpu_mbus_target(const struct orion_addr_map_cfg *cfg,
 		u32 size = readl(ddr_window_cpu_base + DDR_SIZE_CS_OFF(i));
 
 		/*
-		 * Chip select enabled?
+		 * We only take care of entries for which the chip
+		 * select is enabled, and that don't have high base
+		 * address bits set (devices can only access the first
+		 * 32 bits of the memory).
 		 */
-		if (size & 1) {
+		if ((size & 1) && !(base & 0xF)) {
 			struct mbus_dram_window *w;
 
 			w = &orion_mbus_dram_info.cs[cs++];
-- 
1.7.9.5

[PATCH 2/4] arm: plat-orion: fix address decoding when > 4GB is used

[Jason Cooper]

On Wed, Mar 06, 2013 at 11:23:34AM +0100, Thomas Petazzoni wrote:
...
> This is a slightly updated version compared to the one sent on
> February 27th on LAKML. The earlier version was looking at the three
> low-order bits, but in fact there are four low-order bits to encode
> the high bits of the base address. So the mask was changed from 0x7 to
> 0xF.
> 
> Since I've changed the patch, I haven't kept the Tested-by from Lior
> Amsalem, Gr?gory Clement and Ezequiel Garcia.

Then please don't send this as part of a pull-request.  Threading it
under a pull-request implies that it is ready to be applied, causing
most reviewers/testers to ignore the email.  Please have Lior, Gr?gory,
and Ezequiel retest and report back.

thx,

Jason.

[PATCH 2/4] arm: plat-orion: fix address decoding when > 4GB is used

[Thomas Petazzoni]

Dear Jason Cooper,

On Wed, 6 Mar 2013 19:30:22 -0500, Jason Cooper wrote:

> > Since I've changed the patch, I haven't kept the Tested-by from Lior
> > Amsalem, Gr?gory Clement and Ezequiel Garcia.
> 
> Then please don't send this as part of a pull-request.  Threading it
> under a pull-request implies that it is ready to be applied, causing
> most reviewers/testers to ignore the email.  Please have Lior,
> Gr?gory, and Ezequiel retest and report back.

I believe it is ready to be applied. The change I've done from the
version tested by others is minor, and I'm quite convinced that the
change is OK. If the change had been more significant, I would for sure
not have sent this as a pull request.

Best regards,

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

[PATCH 2/4] arm: plat-orion: fix address decoding when > 4GB is used

[Ezequiel Garcia]

On Wed, Mar 06, 2013 at 11:23:34AM +0100, Thomas Petazzoni wrote:
> During the system initialization, the orion_setup_cpu_mbus_target()
> function reads the SDRAM address decoding registers to find out how
> many chip-selects of SDRAM have been enabled, and builds a small array
> with one entry per chip-select. This array is then used by device
> drivers (XOR, Ethernet, etc.) to configure their own address decoding
> windows to the SDRAM.
> 
> However, devices can only access the first 32 bits of the physical
> memory. Even though LPAE is not supported for now, some Marvell boards
> are now showing up with 8 GB of RAM, configured using two SDRAM
> address decoding windows: the first covering the first 4 GB, the
> second covering the last 4 GB. The array built by
> orion_setup_cpu_mbus_target() has therefore two entries, and device
> drivers try to set up two address decoding windows to the
> SDRAM. However, in the device registers for the address decoding, the
> base address is only 32 bits, so those two windows overlap each other,
> and the devices do not work at all.
> 
> This patch makes sure that the array built by
> orion_setup_cpu_mbus_target() only contains the SDRAM decoding windows
> that correspond to the first 4 GB of the memory. To do that, it
> ignores the SDRAM decoding windows for which the 4 low-order bits are
> not zero (the 4 low-order bits of the base register are used to store
> bits 32:35 of the base address, so they actually indicate whether the
> base address is above 4 GB).
> 
> This patch allows the newly introduced armada-xp-gp board to properly
> operate when it is mounted with more than 4 GB of RAM. Without that,
> all devices doing DMA (for example XOR and Ethernet) do not work at
> all.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH 3/4] arm: mvebu: fix address-cells in mpic DT node

[Thomas Petazzoni]

There is no need to have a #address-cells property in the MPIC Device
Tree node, and more than that, having it confuses the of_irq_map_raw()
logic, which will be used by the Marvell PCIe driver.

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

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 99afca4..5b70820 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -31,7 +31,6 @@
 	mpic: interrupt-controller at d0020000 {
 	      compatible = "marvell,mpic";
 	      #interrupt-cells = <1>;
-	      #address-cells = <1>;
 	      #size-cells = <1>;
 	      interrupt-controller;
 	};
-- 
1.7.9.5

[PATCH 4/4] arm: mach-orion5x: fix typo in compatible string of a .dts file

[Thomas Petazzoni]

The orion5x-lacie-ethernet-disk-mini-v2.dts file was using
"marvell-orion5x-88f5182" as a compatible string, while it should have
been "marvell,orion5x-88f5182".

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
index 5a3a58b..0077fc8 100644
--- a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
+++ b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
@@ -11,7 +11,7 @@
 
 / {
 	model = "LaCie Ethernet Disk mini V2";
-	compatible = "lacie,ethernet-disk-mini-v2", "marvell-orion5x-88f5182", "marvell,orion5x";
+	compatible = "lacie,ethernet-disk-mini-v2", "marvell,orion5x-88f5182", "marvell,orion5x";
 
 	memory {
 		reg = <0x00000000 0x4000000>; /* 64 MB */
-- 
1.7.9.5

[GIT PULL 3.9] Various fixes for Marvell EBU platforms

[Jason Cooper]

On Wed, Mar 06, 2013 at 11:23:32AM +0100, Thomas Petazzoni wrote:
> Jason, Andrew, Greg,
> 
> Here are four fixes for Marvell EBU platforms. The first fix is very
> important, without it, all Armada 370/XP platforms are broken. The
> second fix is important as well because it makes the Armada XP GP
> platform actually usable (without it, the platform boots, but no
> network, no XOR, almost nothing works). The two other patches are
> minor DT fixes.
> 
> Thanks.
> 
> The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
> 
>   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
> 
> are available in the git repository at:
> 
>   git at github.com:MISL-EBU-System-SW/mainline-public.git tags/marvell-3.9-fixes-tag
> 
> for you to fetch changes up to 6e025ae424c90febf2d0ad4368f0e5cba8b46f77:
> 
>   arm: mach-orion5x: fix typo in compatible string of a .dts file (2013-03-06 10:32:59 +0100)
> 
> ----------------------------------------------------------------
> Various small fixes for Marvell EBU platforms, intended for 3.9.
> 
> ----------------------------------------------------------------
> Heikki Krogerus (1):
>       arm: mvebu: Reduce reg-io-width with UARTs
> 
> Thomas Petazzoni (3):
>       arm: plat-orion: fix address decoding when > 4GB is used
>       arm: mvebu: fix address-cells in mpic DT node
>       arm: mach-orion5x: fix typo in compatible string of a .dts file
> 
>  arch/arm/boot/dts/armada-370-xp.dtsi               |    5 ++---
>  arch/arm/boot/dts/armada-xp.dtsi                   |    4 ++--
>  .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |    2 +-
>  arch/arm/plat-orion/addr-map.c                     |    7 +++++--
>  4 files changed, 10 insertions(+), 8 deletions(-)

All applied to mvebu/fixes

thx,

Jason.

[GIT PULL 3.9] Various fixes for Marvell EBU platforms

[Thomas Petazzoni]

Dear Jason Cooper,

On Fri, 8 Mar 2013 17:23:17 -0500, Jason Cooper wrote:

> > Heikki Krogerus (1):
> >       arm: mvebu: Reduce reg-io-width with UARTs
> > 
> > Thomas Petazzoni (3):
> >       arm: plat-orion: fix address decoding when > 4GB is used
> >       arm: mvebu: fix address-cells in mpic DT node
> >       arm: mach-orion5x: fix typo in compatible string of a .dts file
> > 
> >  arch/arm/boot/dts/armada-370-xp.dtsi               |    5 ++---
> >  arch/arm/boot/dts/armada-xp.dtsi                   |    4 ++--
> >  .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |    2 +-
> >  arch/arm/plat-orion/addr-map.c                     |    7 +++++--
> >  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> All applied to mvebu/fixes

Thanks!

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