[PATCH 0/5] ARM: mvebu: Add Armada 385 AP support

[PATCH 0/5] ARM: mvebu: Add Armada 385 AP support

[Maxime Ripard]

Hi everyone,

This set of patches add the support for the Armada 385 AP board.

It also adds a few clean ups here and there, a few missing pin
functions needed for the board, etc.

Maxime

Maxime Ripard (5):
  ARM: mvebu: Rename DEBUG_LL to indicate UART index
  ARM: mvebu: Add UART1 as DEBUG_LL possible target
  ARM: mvebu: a38x: Fix node names
  pinctrl: mvebu: a38x: Add UART1 muxing options
  ARM: mvebu: Add Armada 385 Access Point Development Board support

 arch/arm/Kconfig.debug                     |  35 +++--
 arch/arm/boot/dts/Makefile                 |   1 +
 arch/arm/boot/dts/armada-385-ap.dts        | 200 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/armada-385-db.dts        |   2 +-
 arch/arm/boot/dts/armada-385-rd.dts        |   2 +-
 arch/arm/boot/dts/armada-385.dtsi          |   2 +-
 arch/arm/boot/dts/armada-38x.dtsi          |   4 +-
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c |   6 +-
 8 files changed, 236 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/boot/dts/armada-385-ap.dts

-- 
2.2.0

[PATCH 1/5] ARM: mvebu: Rename DEBUG_LL to indicate UART index

[Maxime Ripard]

The mvebu SoCs actually have more UARTs than just the one exposed in DEBUG_LL
yet.

In order to differentiate them, Add the index in the configuration options and
their help.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/Kconfig.debug | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d8f6a2ec3d4e..b0945d6b32b3 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -423,13 +423,13 @@ choice
 		  Please adjust DEBUG_UART_PHYS and DEBUG_UART_BASE configuration
 		  options based on your needs.
 
-	config DEBUG_MVEBU_UART
-		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
+	config DEBUG_MVEBU_UART0
+		bool "Kernel low-level debugging messages via MVEBU UART0 (old bootloaders)"
 		depends on ARCH_MVEBU
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
-		  on MVEBU based platforms.
+		  on MVEBU based platforms on UART0.
 
 		  This option should be used with the old bootloaders
 		  that left the internal registers mapped at
@@ -442,13 +442,13 @@ choice
 		  when u-boot hands over to the kernel, the system
 		  silently crashes, with no serial output at all.
 
-	config DEBUG_MVEBU_UART_ALTERNATE
-		bool "Kernel low-level debugging messages via MVEBU UART (new bootloaders)"
+	config DEBUG_MVEBU_UART0_ALTERNATE
+		bool "Kernel low-level debugging messages via MVEBU UART0 (new bootloaders)"
 		depends on ARCH_MVEBU
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
-		  on MVEBU based platforms.
+		  on MVEBU based platforms on UART0.
 
 		  This option should be used with the new bootloaders
 		  that remap the internal registers at 0xf1000000.
@@ -1146,14 +1146,14 @@ config DEBUG_UART_PHYS
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xd0000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
-	default 0xd0012000 if DEBUG_MVEBU_UART
+	default 0xd0012000 if DEBUG_MVEBU_UART0
 	default 0xc81004c0 if DEBUG_MESON_UARTAO
 	default 0xd4017000 if DEBUG_MMP_UART2
 	default 0xd4018000 if DEBUG_MMP_UART3
 	default 0xe0000000 if ARCH_SPEAR13XX
 	default 0xe4007000 if DEBUG_HIP04_UART
 	default 0xf0000be0 if ARCH_EBSA110
-	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
+	default 0xf1012000 if DEBUG_MVEBU_UART0_ALTERNATE
 	default 0xf1012000 if ARCH_DOVE || ARCH_MV78XX0 || \
 				ARCH_ORION5X
 	default 0xf7fc9000 if DEBUG_BERLIN_UART
@@ -1223,7 +1223,7 @@ config DEBUG_UART_VIRT
 	default 0xfeb30c00 if DEBUG_KEYSTONE_UART0
 	default 0xfeb31000 if DEBUG_KEYSTONE_UART1
 	default 0xfec02000 if DEBUG_SOCFPGA_UART
-	default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE
+	default 0xfec12000 if DEBUG_MVEBU_UART0 || DEBUG_MVEBU_UART0_ALTERNATE
 	default 0xfec20000 if DEBUG_DAVINCI_DMx_UART0
 	default 0xfec90000 if DEBUG_RK32_UART2
 	default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1
-- 
2.2.0

[PATCH 2/5] ARM: mvebu: Add UART1 as DEBUG_LL possible target

[Maxime Ripard]

Some mvebu boards have the UART1 more easily accessible than the other UARTs
found on the system.

Add a debug_ll option for this case.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/Kconfig.debug | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b0945d6b32b3..8f119f5ffcdd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -457,6 +457,21 @@ choice
 		  when u-boot hands over to the kernel, the system
 		  silently crashes, with no serial output at all.
 
+	config DEBUG_MVEBU_UART1_ALTERNATE
+		bool "Kernel low-level debugging messages via MVEBU UART1 (new bootloaders)"
+		depends on ARCH_MVEBU
+		select DEBUG_UART_8250
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on MVEBU based platforms on UART1.
+
+		  This option should be used with the new bootloaders
+		  that remap the internal registers at 0xf1000000.
+
+		  If the wrong DEBUG_MVEBU_UART* option is selected,
+		  when u-boot hands over to the kernel, the system
+		  silently crashes, with no serial output at all.
+
 	config DEBUG_VF_UART
 		bool "Vybrid UART"
 		depends on SOC_VF610
@@ -1154,6 +1169,7 @@ config DEBUG_UART_PHYS
 	default 0xe4007000 if DEBUG_HIP04_UART
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf1012000 if DEBUG_MVEBU_UART0_ALTERNATE
+	default 0xf1012100 if DEBUG_MVEBU_UART1_ALTERNATE
 	default 0xf1012000 if ARCH_DOVE || ARCH_MV78XX0 || \
 				ARCH_ORION5X
 	default 0xf7fc9000 if DEBUG_BERLIN_UART
@@ -1224,6 +1240,7 @@ config DEBUG_UART_VIRT
 	default 0xfeb31000 if DEBUG_KEYSTONE_UART1
 	default 0xfec02000 if DEBUG_SOCFPGA_UART
 	default 0xfec12000 if DEBUG_MVEBU_UART0 || DEBUG_MVEBU_UART0_ALTERNATE
+	default 0xfec12100 if DEBUG_MVEBU_UART1_ALTERNATE
 	default 0xfec20000 if DEBUG_DAVINCI_DMx_UART0
 	default 0xfec90000 if DEBUG_RK32_UART2
 	default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1
-- 
2.2.0

[PATCH 3/5] ARM: mvebu: a38x: Fix node names

[Maxime Ripard]

Some nodes in the DTs have a reg property but no unit name in their node name.

This contradicts the way the ePAPR defines the node names. Fix this.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/armada-385-db.dts | 2 +-
 arch/arm/boot/dts/armada-385-rd.dts | 2 +-
 arch/arm/boot/dts/armada-385.dtsi   | 2 +-
 arch/arm/boot/dts/armada-38x.dtsi   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
index 1af886f1e486..d2ad03e08c17 100644
--- a/arch/arm/boot/dts/armada-385-db.dts
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -74,7 +74,7 @@
 				phy-mode = "rgmii-id";
 			};
 
-			mdio {
+			mdio at 72004 {
 				phy0: ethernet-phy at 0 {
 					reg = <0>;
 				};
diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
index aaca2861dc87..74a3bfe6efd7 100644
--- a/arch/arm/boot/dts/armada-385-rd.dts
+++ b/arch/arm/boot/dts/armada-385-rd.dts
@@ -67,7 +67,7 @@
 			};
 
 
-			mdio {
+			mdio at 72004 {
 				phy0: ethernet-phy at 0 {
 					reg = <0>;
 				};
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
index 6283d7912f71..5249a4d3c207 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -37,7 +37,7 @@
 
 	soc {
 		internal-regs {
-			pinctrl {
+			pinctrl at 18000 {
 				compatible = "marvell,mv88f6820-pinctrl";
 				reg = <0x18000 0x20>;
 			};
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 242d0ecc99f3..221cca4e79fc 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -193,7 +193,7 @@
 				status = "disabled";
 			};
 
-			pinctrl {
+			pinctrl at 18000 {
 				compatible = "marvell,mv88f6820-pinctrl";
 				reg = <0x18000 0x20>;
 			};
@@ -373,7 +373,7 @@
 				status = "disabled";
 			};
 
-			mdio {
+			mdio at 72004 {
 				#address-cells = <1>;
 				#size-cells = <0>;
 				compatible = "marvell,orion-mdio";
-- 
2.2.0

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Maxime Ripard]

The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
function.

Add this case to the pinctrl driver.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
index 1049f82fb62f..fd743fab07f5 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
@@ -145,14 +145,16 @@ static struct mvebu_mpp_mode armada_38x_mpp_modes[] = {
 		 MPP_VAR_FUNCTION(2, "ptp",   "event_req",  V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(3, "pcie0", "clkreq",     V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(4, "sata1", "prsnt",      V_88F6810_PLUS),
-		 MPP_VAR_FUNCTION(5, "ua0",   "cts",        V_88F6810_PLUS)),
+		 MPP_VAR_FUNCTION(5, "ua0",   "cts",        V_88F6810_PLUS),
+		 MPP_VAR_FUNCTION(6, "ua1",   "rxd",        V_88F6810_PLUS)),
 	MPP_MODE(20,
 		 MPP_VAR_FUNCTION(0, "gpio",  NULL,         V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(1, "ge0",   "txclk",      V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(2, "ptp",   "clk",        V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(3, "pcie1", "rstout",     V_88F6820_PLUS),
 		 MPP_VAR_FUNCTION(4, "sata0", "prsnt",      V_88F6810_PLUS),
-		 MPP_VAR_FUNCTION(5, "ua0",   "rts",        V_88F6810_PLUS)),
+		 MPP_VAR_FUNCTION(5, "ua0",   "rts",        V_88F6810_PLUS),
+		 MPP_VAR_FUNCTION(6, "ua1",   "txd",        V_88F6810_PLUS)),
 	MPP_MODE(21,
 		 MPP_VAR_FUNCTION(0, "gpio",  NULL,         V_88F6810_PLUS),
 		 MPP_VAR_FUNCTION(1, "spi0",  "cs1",        V_88F6810_PLUS),
-- 
2.2.0

[PATCH 5/5] ARM: mvebu: Add Armada 385 Access Point Development Board support

[Maxime Ripard]

The A385-AP is a board produced by Marvell that holds 3 mPCIe slot, a 16MB
SPI-NOR, 3 Gigabit Ethernet ports, USB3 and NAND flash storage.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/Makefile          |   1 +
 arch/arm/boot/dts/armada-385-ap.dts | 200 ++++++++++++++++++++++++++++++++++++
 2 files changed, 201 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-ap.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89cafa1ab..363fdeaa0368 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -499,6 +499,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
 dtb-$(CONFIG_MACH_ARMADA_375) += \
 	armada-375-db.dtb
 dtb-$(CONFIG_MACH_ARMADA_38X) += \
+	armada-385-ap.dtb \
 	armada-385-db.dtb \
 	armada-385-rd.dtb
 dtb-$(CONFIG_MACH_ARMADA_XP) += \
diff --git a/arch/arm/boot/dts/armada-385-ap.dts b/arch/arm/boot/dts/armada-385-ap.dts
new file mode 100644
index 000000000000..915b4438c15d
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-ap.dts
@@ -0,0 +1,200 @@
+/*
+ * Device Tree file for Marvell Armada 385 Access Point Development board
+ * (DB-88F6820-AP)
+ *
+ *  Copyright (C) 2014 Marvell
+ *
+ * Nadav Haklai <nadavh@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Marvell Armada 385 Access Point Development Board";
+	compatible = "marvell,a385-db-ap", "marvell,armada385", "marvell,armada38x";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000>; /* 2GB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000	/* CESA0: PHYS=0xf1100000
+									   size 64K */
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;	/* CESA1: PHYS=0xf1110000
+									   size 64K */
+
+		internal-regs {
+			spi1: spi at 10680 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&spi1_pins>;
+				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "st,m25p128";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
+			};
+
+			i2c0: i2c at 11000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&i2c0_pins>;
+				status = "okay";
+				clock-frequency = <100000>;
+			};
+
+			i2c1: i2c at 11100 {
+				status = "okay";
+				clock-frequency = <100000>;
+			};
+
+			mdio at 72004 {
+				pinctrl-names = <&phy_pins>;
+
+				phy0: ethernet-phy at 0 {
+					reg = <1>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <6>;
+				};
+
+				phy2: ethernet-phy at 2 {
+					reg = <4>;
+				};
+			};
+
+			uart0: serial at 12000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&uart0_pins>;
+				status = "okay";
+			};
+
+			uart1: serial at 12100 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&uart1_pins>;
+				status = "okay";
+			};
+
+			pinctrl at 18000 {
+				ge0_pins: ge-pins-0 {
+					marvell,pins = "mpp6", "mpp7", "mpp8",
+						       "mpp9", "mpp10", "mpp11",
+						       "mpp12", "mpp13", "mpp14",
+						       "mpp15", "mpp16", "mpp17";
+					marvell,function = "ge0";
+				};
+
+				i2c0_pins: i2c-pins-0 {
+					marvell,pins = "mpp2", "mpp3";
+					marvell,function = "i2c0";
+				};
+
+				phy_pins: phy-pins {
+					marvell,pins = "mpp4", "mpp5";
+					marvell,function = "ge";
+				};
+
+				ref_clk0_pins: ref-clk-pins-0 {
+					marvell,pins = "mpp45";
+					marvell,function = "ref";
+				};
+
+				spi1_pins: spi-pins-1 {
+					marvell,pins = "mpp56", "mpp57", "mpp58",
+						       "mpp59";
+					marvell,function = "spi1";
+				};
+
+				uart0_pins: uart-pins-0 {
+					marvell,pins = "mpp0", "mpp1";
+					marvell,function = "ua0";
+				};
+
+				uart1_pins: uart-pins-1 {
+					marvell,pins = "mpp19", "mpp20";
+					marvell,function = "ua1";
+				};
+
+				xhci0_vbus_pins: xhci0-vbus-pins {
+					marvell,pins = "mpp44";
+					marvell,function = "gpio";
+				};
+			};
+
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "sgmii";
+			};
+
+			ethernet at 34000 {
+				status = "okay";
+				phy = <&phy2>;
+				phy-mode = "sgmii";
+			};
+
+			ethernet at 70000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&ge0_pins>, <&ref_clk0_pins>;
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+
+			usb3 at f0000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+			/*
+			 * The two PCIe units are accessible through
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 3,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+
+	reg_xhci0_vbus: xhci0-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&xhci0_vbus_pins>;
+		regulator-name = "xhci0-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		regulator-always-on;
+		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+	};
+};
-- 
2.2.0

[PATCH 2/5] ARM: mvebu: Add UART1 as DEBUG_LL possible target

[Jason Cooper]

Maxime,

On Fri, Dec 05, 2014 at 03:44:55PM +0100, Maxime Ripard wrote:
> Some mvebu boards have the UART1 more easily accessible than the other UARTs
> found on the system.
> 
> Add a debug_ll option for this case.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  arch/arm/Kconfig.debug | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

It looks to me like patches 1 and 2 should go through
Russell's patch tracker.  Is it worth having two patches?

In either case,

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Jason Cooper]

On Fri, Dec 05, 2014 at 03:44:57PM +0100, Maxime Ripard wrote:
> The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
> function.
> 
> Add this case to the pinctrl driver.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

[PATCH 2/5] ARM: mvebu: Add UART1 as DEBUG_LL possible target

[Arnd Bergmann]

On Friday 05 December 2014 10:25:03 Jason Cooper wrote:
> On Fri, Dec 05, 2014 at 03:44:55PM +0100, Maxime Ripard wrote:
> > Some mvebu boards have the UART1 more easily accessible than the other UARTs
> > found on the system.
> > 
> > Add a debug_ll option for this case.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >  arch/arm/Kconfig.debug | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> 
> It looks to me like patches 1 and 2 should go through
> Russell's patch tracker.  Is it worth having two patches?
> 
> In either case,
> 
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> 

This kind of change to Kconfig.debug frequently goes together with
soc support, so we have started merging them through arm-soc

	Arnd

[PATCH 5/5] ARM: mvebu: Add Armada 385 Access Point Development Board support

[Arnd Bergmann]

On Friday 05 December 2014 15:44:58 Maxime Ripard wrote:
> +       chosen {
> +               bootargs = "console=ttyS0,115200 earlyprintk";
> +       };

We should stop using earlyprintk as the default bootargs. It's always been
problematic in case you have a kernel that contains the wrong debug_ll
stub, and starting from 3.19, we should have a working earlycon support.

	Arnd

[PATCH 0/5] ARM: mvebu: Add Armada 385 AP support

[Andrew Lunn]

On Fri, Dec 05, 2014 at 03:44:53PM +0100, Maxime Ripard wrote:
> Hi everyone,
> 
> This set of patches add the support for the Armada 385 AP board.
> 
> It also adds a few clean ups here and there, a few missing pin
> functions needed for the board, etc.

Hi Maxime

Have you seen

https://www.mail-archive.com/devicetree at vger.kernel.org/msg51931.html

It made quite a few cleanups to 370 and XP pinctrl nodes, labels, etc.
I think quite a few of those cleanups should also be applied to 385.

  Andrew

> 
> Maxime
> 
> Maxime Ripard (5):
>   ARM: mvebu: Rename DEBUG_LL to indicate UART index
>   ARM: mvebu: Add UART1 as DEBUG_LL possible target
>   ARM: mvebu: a38x: Fix node names
>   pinctrl: mvebu: a38x: Add UART1 muxing options
>   ARM: mvebu: Add Armada 385 Access Point Development Board support
> 
>  arch/arm/Kconfig.debug                     |  35 +++--
>  arch/arm/boot/dts/Makefile                 |   1 +
>  arch/arm/boot/dts/armada-385-ap.dts        | 200 +++++++++++++++++++++++++++++
>  arch/arm/boot/dts/armada-385-db.dts        |   2 +-
>  arch/arm/boot/dts/armada-385-rd.dts        |   2 +-
>  arch/arm/boot/dts/armada-385.dtsi          |   2 +-
>  arch/arm/boot/dts/armada-38x.dtsi          |   4 +-
>  drivers/pinctrl/mvebu/pinctrl-armada-38x.c |   6 +-
>  8 files changed, 236 insertions(+), 16 deletions(-)
>  create mode 100644 arch/arm/boot/dts/armada-385-ap.dts
> 
> -- 
> 2.2.0
> 

[PATCH 5/5] ARM: mvebu: Add Armada 385 Access Point Development Board support

[Thomas Petazzoni]

Dear Maxime Ripard,

On Fri,  5 Dec 2014 15:44:58 +0100, Maxime Ripard wrote:

> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> +			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000	/* CESA0: PHYS=0xf1100000
> +									   size 64K */
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;	/* CESA1: PHYS=0xf1110000
> +									   size 64K */

Those two last ranges are not needed, and may not necessarily match what
we decide to do with the crypto engine support later on.

> +			mdio at 72004 {
> +				pinctrl-names = <&phy_pins>;

These are not really "PHY" pins, but rather MDIO pins.

> +			pinctrl at 18000 {
> +				ge0_pins: ge-pins-0 {
> +					marvell,pins = "mpp6", "mpp7", "mpp8",
> +						       "mpp9", "mpp10", "mpp11",
> +						       "mpp12", "mpp13", "mpp14",
> +						       "mpp15", "mpp16", "mpp17";
> +					marvell,function = "ge0";
> +				};

This seems like the normal pin muxing for RGMII, so maybe we should
simply do like we did for Armada 370: have a ge0-rgmii-pins definition
in the .dtsi file.

> +				i2c0_pins: i2c-pins-0 {
> +					marvell,pins = "mpp2", "mpp3";
> +					marvell,function = "i2c0";
> +				};

Same question here, maybe define it in .dtsi ?

> +
> +				phy_pins: phy-pins {
> +					marvell,pins = "mpp4", "mpp5";
> +					marvell,function = "ge";
> +				};

Same here.

> +
> +				ref_clk0_pins: ref-clk-pins-0 {
> +					marvell,pins = "mpp45";
> +					marvell,function = "ref";
> +				};
> +
> +				spi1_pins: spi-pins-1 {
> +					marvell,pins = "mpp56", "mpp57", "mpp58",
> +						       "mpp59";
> +					marvell,function = "spi1";
> +				};
> +
> +				uart0_pins: uart-pins-0 {
> +					marvell,pins = "mpp0", "mpp1";
> +					marvell,function = "ua0";
> +				};
> +
> +				uart1_pins: uart-pins-1 {
> +					marvell,pins = "mpp19", "mpp20";
> +					marvell,function = "ua1";
> +				};
> +
> +				xhci0_vbus_pins: xhci0-vbus-pins {
> +					marvell,pins = "mpp44";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
> +			ethernet at 30000 {
> +				status = "okay";
> +				phy = <&phy1>;
> +				phy-mode = "sgmii";
> +			};
> +
> +			ethernet at 34000 {
> +				status = "okay";
> +				phy = <&phy2>;
> +				phy-mode = "sgmii";
> +			};
> +
> +			ethernet at 70000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&ge0_pins>, <&ref_clk0_pins>;

Maybe a short comment about what this ref_clk0_pins is useful for would
be nice.

> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			usb3 at f0000 {
> +				status = "okay";
> +			};

The board also has an USB2 connector, did you try enabling it?

> +		};
> +
> +		pcie-controller {
> +			status = "okay";
> +			/*
> +			 * The two PCIe units are accessible through
> +			 * standard PCIe slots on the board.

Two, or three ? :-)

> +			 */
> +			pcie at 1,0 {
> +				/* Port 0, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie at 2,0 {
> +				/* Port 1, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie at 3,0 {
> +				/* Port 2, Lane 0 */
> +				status = "okay";
> +			};
> +		};
> +	};
> +
> +	reg_xhci0_vbus: xhci0-vbus {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&xhci0_vbus_pins>;
> +		regulator-name = "xhci0-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		regulator-always-on;
> +		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
> +	};

Maybe you could connect this to the USB controller by using the
usb-nop-xceiv thing (which acts as a dummy USB PHY, if I understood
correctly) ?

Thanks!

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

[PATCH 5/5] ARM: mvebu: Add Armada 385 Access Point Development Board support

[Gregory CLEMENT]

Hi Maxime,

[...]

>> +		};
>> +
>> +		pcie-controller {
>> +			status = "okay";
>> +			/*
>> +			 * The two PCIe units are accessible through
>> +			 * standard PCIe slots on the board.
> 
> Two, or three ? :-)

Actually there are 3 PCIe units accessible through miniPCIe slots
and not standard PCIe slots.

> 
>> +			 */
>> +			pcie at 1,0 {
>> +				/* Port 0, Lane 0 */
>> +				status = "okay";
>> +			};
>> +
>> +			pcie at 2,0 {
>> +				/* Port 1, Lane 0 */
>> +				status = "okay";
>> +			};
>> +
>> +			pcie at 3,0 {
>> +				/* Port 2, Lane 0 */
>> +				status = "okay";
>> +			};
>> +		};
>> +	};
>> +
>> +	reg_xhci0_vbus: xhci0-vbus {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&xhci0_vbus_pins>;
>> +		regulator-name = "xhci0-vbus";
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		enable-active-high;
>> +		regulator-always-on;
>> +		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
>> +	};
> 
> Maybe you could connect this to the USB controller by using the
> usb-nop-xceiv thing (which acts as a dummy USB PHY, if I understood
> correctly) ?
> 
> Thanks!
> 
> Thomas
> 


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

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Linus Walleij]

On Fri, Dec 5, 2014 at 3:44 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:

> The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
> function.
>
> Add this case to the pinctrl driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Patch applied with Jason's ACK.

Yours,
Linus Walleij

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Jason Cooper]

On Fri, Jan 09, 2015 at 11:05:53AM +0100, Linus Walleij wrote:
> On Fri, Dec 5, 2014 at 3:44 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> 
> > The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
> > function.
> >
> > Add this case to the pinctrl driver.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> 
> Patch applied with Jason's ACK.

I did?

thx,

Jason.

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Linus Walleij]

On Fri, Jan 9, 2015 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Jan 09, 2015 at 11:05:53AM +0100, Linus Walleij wrote:
>> On Fri, Dec 5, 2014 at 3:44 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>
>> > The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
>> > function.
>> >
>> > Add this case to the pinctrl driver.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>
>> Patch applied with Jason's ACK.
>
> I did?

Yeah...

Date: Fri, 5 Dec 2014 10:26:26 -0500
From: Jason Cooper <jason@lakedaemon.net>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Gregory Clement <gregory.clement@free-electrons.com>,
Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Thomas Petazzoni <thomas@free-electrons.com>,
linux-arm-kernel at lists.infradead.org,
Tawfik Bayouk <tawfik@marvell.com>,
Nadav Haklai <nadavh@marvell.com>, Lior Amsalem <alior@marvell.com>
Subject: Re: [PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options
Message-ID: <20141205152626.GF22670@titan.lakedaemon.net>
References: <1417790698-9792-1-git-send-email-maxime.ripard@free-electrons.com>
 <1417790698-9792-5-git-send-email-maxime.ripard@free-electrons.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1417790698-9792-5-git-send-email-maxime.ripard@free-electrons.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Fri, Dec 05, 2014 at 03:44:57PM +0100, Maxime Ripard wrote:
> The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
> function.
>
> Add this case to the pinctrl driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.


Yours,
Linus Walleij

[PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options

[Jason Cooper]

On Sat, Jan 10, 2015 at 10:44:00PM +0100, Linus Walleij wrote:
> On Fri, Jan 9, 2015 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Fri, Jan 09, 2015 at 11:05:53AM +0100, Linus Walleij wrote:
> >> On Fri, Dec 5, 2014 at 3:44 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >>
> >> > The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
> >> > function.
> >> >
> >> > Add this case to the pinctrl driver.
> >> >
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>
> >> Patch applied with Jason's ACK.
> >
> > I did?
> 
> Yeah...
> 
> Date: Fri, 5 Dec 2014 10:26:26 -0500

Ahhh.... *before* Christmas.  My memory is quickly degrading.

thx,

Jason.