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

[PATCH v2 0/7] 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

Changes from v1:
  - Removed USB3 support. This required some additional patches for
    the phy and USB drivers that are not really related to this
    serie. This will be submitted as a separate one.
  - Removed earlyprintk from the default bootargs
  - Removed two unneeded ranges
  - Changed the phy pins node name to mdio
  - Moved most of the pinctrl nodes to the DTSI
  - Added a comment to mention why the phy reference clock is needed.
  - Rebased on top of 3.19-rc1

Maxime Ripard (7):
  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: A38x: Remove redundant pinctrl informations
  ARM: mvebu: Add a number of pinctrl functions
  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-380.dtsi          |   3 +-
 arch/arm/boot/dts/armada-385-ap.dts        | 140 +++++++++++++++++++++++++++++
 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          |   3 +-
 arch/arm/boot/dts/armada-38x.dtsi          |  44 ++++++++-
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c |   6 +-
 9 files changed, 216 insertions(+), 20 deletions(-)
 create mode 100644 arch/arm/boot/dts/armada-385-ap.dts

-- 
2.2.1

[PATCH v2 1/7] 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>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
 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 5ddd4906f7a7..eb3991cf63ab 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -455,13 +455,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
@@ -474,13 +474,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.
@@ -1282,7 +1282,7 @@ 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
@@ -1296,7 +1296,7 @@ config DEBUG_UART_PHYS
 	default 0xe8008000 if DEBUG_R7S72100_SCIF2
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf040ab00 if DEBUG_BRCMSTB_UART
-	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
@@ -1377,7 +1377,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.1

[PATCH v2 2/7] 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>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
 arch/arm/Kconfig.debug | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index eb3991cf63ab..7bd1bbccc43c 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -489,6 +489,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
@@ -1297,6 +1312,7 @@ config DEBUG_UART_PHYS
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf040ab00 if DEBUG_BRCMSTB_UART
 	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
@@ -1378,6 +1394,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.1

[PATCH v2 3/7] 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-380.dtsi   | 2 +-
 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 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-380.dtsi b/arch/arm/boot/dts/armada-380.dtsi
index 4173a8ab34e7..13400ce88c54 100644
--- a/arch/arm/boot/dts/armada-380.dtsi
+++ b/arch/arm/boot/dts/armada-380.dtsi
@@ -32,7 +32,7 @@
 
 	soc {
 		internal-regs {
-			pinctrl {
+			pinctrl at 18000 {
 				compatible = "marvell,mv88f6810-pinctrl";
 				reg = <0x18000 0x20>;
 			};
diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
index 2aaa9d2ac284..212605ccc7b6 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 74391dace9e7..ada1f206028b 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.1

[PATCH v2 4/7] 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>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
 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 224c6cff6aa2..7302f66f4f19 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.1

[PATCH v2 5/7] ARM: mvebu: A38x: Remove redundant pinctrl informations

[Maxime Ripard]

The compatible set in the armada-38x DTSI is always overridden, and the reg
defined in there is duplicated in the armada-380 and armada-385 DTSIs.

Remove these useless items.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/armada-380.dtsi | 1 -
 arch/arm/boot/dts/armada-385.dtsi | 1 -
 arch/arm/boot/dts/armada-38x.dtsi | 1 -
 3 files changed, 3 deletions(-)

diff --git a/arch/arm/boot/dts/armada-380.dtsi b/arch/arm/boot/dts/armada-380.dtsi
index 13400ce88c54..7e509d2d74d0 100644
--- a/arch/arm/boot/dts/armada-380.dtsi
+++ b/arch/arm/boot/dts/armada-380.dtsi
@@ -34,7 +34,6 @@
 		internal-regs {
 			pinctrl at 18000 {
 				compatible = "marvell,mv88f6810-pinctrl";
-				reg = <0x18000 0x20>;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
index 5249a4d3c207..a54a252ddb4c 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -39,7 +39,6 @@
 		internal-regs {
 			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 ada1f206028b..40200084c6c8 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -194,7 +194,6 @@
 			};
 
 			pinctrl at 18000 {
-				compatible = "marvell,mv88f6820-pinctrl";
 				reg = <0x18000 0x20>;
 			};
 
-- 
2.2.1

[PATCH v2 6/7] ARM: mvebu: Add a number of pinctrl functions

[Maxime Ripard]

Some pinctrl functions can be shared with all DTS out there, since they are
generic, SoC-wide muxing options. Add a number of these to the DTSI to avoid
duplication.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/armada-38x.dtsi | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 40200084c6c8..98885c58be29 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -195,6 +195,45 @@
 
 			pinctrl at 18000 {
 				reg = <0x18000 0x20>;
+
+				ge0_rgmii_pins: ge-rgmii-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";
+				};
+
+				mdio_pins: mdio-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";
+				};
 			};
 
 			gpio0: gpio at 18100 {
-- 
2.2.1

[PATCH v2 7/7] 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 | 140 ++++++++++++++++++++++++++++++++++++
 2 files changed, 141 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 91bd5bd62857..3faf688564d4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -534,6 +534,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..ab88dc4be636
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-ap.dts
@@ -0,0 +1,140 @@
+/*
+ * 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";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000>; /* 2GB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+		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 = <&mdio_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";
+			};
+
+			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";
+
+				/*
+				 * The Reference Clock 0 is used to
+				 * provide a clock to the PHY
+				 */
+				pinctrl-0 = <&ge0_rgmii_pins>, <&ref_clk0_pins>;
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The three PCIe units are accessible through
+			 * standard mini-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";
+			};
+		};
+	};
+};
-- 
2.2.1

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

[Andrew Lunn]

On Tue, Jan 06, 2015 at 04:28:20PM +0100, Maxime Ripard wrote:

Hi Maxime

> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-ap.dts
> @@ -0,0 +1,140 @@
> +/*
> + * 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.
> + */

Gregory is in the process of dual licensing some of the other mvebu DT
files. This one is single license. Should it be dual?

> +
> +/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";

Humm, ttyS0? Then why add the LL_DEBUG via UART1?

Maybe add

stdout-path = &uart1;

> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x80000000>; /* 2GB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> +
> +		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>;
> +			};

Is there anything on these two i2c busses? If not, why enable them and
increase the clock speed?

> +			mdio at 72004 {
> +				pinctrl-names = <&mdio_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";
> +			};

If it is not obvious from the silk screen, could you describe which
connector this uart is on, what pins are what?

> +
> +			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";
> +
> +				/*
> +				 * The Reference Clock 0 is used to
> +				 * provide a clock to the PHY
> +				 */

Does this clock need enabling? Should it be listed in the clocks
property?

Thanks
	Andrew

> +				pinctrl-0 = <&ge0_rgmii_pins>, <&ref_clk0_pins>;
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +		};
> +
> +		pcie-controller {
> +			status = "okay";
> +
> +			/*
> +			 * The three PCIe units are accessible through
> +			 * standard mini-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";
> +			};
> +		};
> +	};
> +};
> -- 
> 2.2.1
> 

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

[Maxime Ripard]

Hi Andrew,

On Tue, Jan 06, 2015 at 04:57:05PM +0100, Andrew Lunn wrote:
> On Tue, Jan 06, 2015 at 04:28:20PM +0100, Maxime Ripard wrote:
> 
> Hi Maxime
> 
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-ap.dts
> > @@ -0,0 +1,140 @@
> > +/*
> > + * 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.
> > + */
> 
> Gregory is in the process of dual licensing some of the other mvebu DT
> files. This one is single license. Should it be dual?

I'm not the original author though. Nadav, would you be ok to make a
switch to a GPL/X11 dual-license?

> > +
> > +/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";
> 
> Humm, ttyS0? Then why add the LL_DEBUG via UART1?

Yeah, my bad :)

It's obviously ttyS1

> Maybe add
> 
> stdout-path = &uart1;

Does that even work with the 8250? Last time I tried with a 3.18, it
didn't, and you still needed the console= bootargs.

> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x00000000 0x80000000>; /* 2GB */
> > +	};
> > +
> > +	soc {
> > +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> > +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> > +
> > +		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>;
> > +			};
> 
> Is there anything on these two i2c busses?

One goes to some pin of the mPCIe slot, the other is connected to the
EEPROM.

> If not, why enable them and increase the clock speed?

The clock speed is not increased, it's actually the driver's default.

> 
> > +			mdio at 72004 {
> > +				pinctrl-names = <&mdio_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";
> > +			};
> 
> If it is not obvious from the silk screen, could you describe which
> connector this uart is on, what pins are what?

There's two UART connectors documented in the user guide (JP8 and
JP9). UART1 is also connected to a FTDI chip, that is exposed through
a mini-USB connector.

> > +
> > +			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";
> > +
> > +				/*
> > +				 * The Reference Clock 0 is used to
> > +				 * provide a clock to the PHY
> > +				 */
> 
> Does this clock need enabling? Should it be listed in the clocks
> property?

>From what I understood, this clock is always running, it's just
exposed to some external pin, and hence needs some muxing.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150106/cd39c0b5/attachment.sig>

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

[Andrew Lunn]

Hi Maxime

> > Maybe add
> > 
> > stdout-path = &uart1;
> 
> Does that even work with the 8250? Last time I tried with a 3.18, it
> didn't, and you still needed the console= bootargs.

It is for the bootloader, not Linux. barebox will use this, etc.  I
think there are also plans for linux to use this. Not sure how far it
has got.

> > > +			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>;
> > > +			};
> > 
> > Is there anything on these two i2c busses?
> 
> One goes to some pin of the mPCIe slot, the other is connected to the
> EEPROM.

So could you add the EEPROM, and a comment about the mPCIe slot?

> > If not, why enable them and increase the clock speed?
> 
> The clock speed is not increased, it's actually the driver's default.

Dio you need this then? Is it in the dtsi file?

> > > +			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";
> > > +			};
> > 
> > If it is not obvious from the silk screen, could you describe which
> > connector this uart is on, what pins are what?
> 
> There's two UART connectors documented in the user guide (JP8 and
> JP9). UART1 is also connected to a FTDI chip, that is exposed through
> a mini-USB connector.

I'm guessing the user guide is only available under NDA? Where as you
can get the hardware without an NDA. At least i have a 370-rd, but no
NDA. So some minimal documentation would be nice. Especially since it
is backwards around to what most people would expect.
 
> > > +
> > > +			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";
> > > +
> > > +				/*
> > > +				 * The Reference Clock 0 is used to
> > > +				 * provide a clock to the PHY
> > > +				 */
> > 
> > Does this clock need enabling? Should it be listed in the clocks
> > property?
> 
> From what I understood, this clock is always running, it's just
> exposed to some external pin, and hence needs some muxing.

O.K, thanks for the explanation.

     Andrew

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

[Gregory CLEMENT]

Hi Maxime,

On 06/01/2015 16:28, Maxime Ripard wrote:
> 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>
> Acked-by: Jason Cooper <jason@lakedaemon.net>

Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory

> ---
>  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 5ddd4906f7a7..eb3991cf63ab 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -455,13 +455,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
> @@ -474,13 +474,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.
> @@ -1282,7 +1282,7 @@ 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
> @@ -1296,7 +1296,7 @@ config DEBUG_UART_PHYS
>  	default 0xe8008000 if DEBUG_R7S72100_SCIF2
>  	default 0xf0000be0 if ARCH_EBSA110
>  	default 0xf040ab00 if DEBUG_BRCMSTB_UART
> -	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
> @@ -1377,7 +1377,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
> 


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

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

[Gregory CLEMENT]

Hi Maxime,

On 06/01/2015 16:28, 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>
> Acked-by: Jason Cooper <jason@lakedaemon.net>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory
> ---
>  arch/arm/Kconfig.debug | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index eb3991cf63ab..7bd1bbccc43c 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -489,6 +489,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
> @@ -1297,6 +1312,7 @@ config DEBUG_UART_PHYS
>  	default 0xf0000be0 if ARCH_EBSA110
>  	default 0xf040ab00 if DEBUG_BRCMSTB_UART
>  	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
> @@ -1378,6 +1394,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
> 


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

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

[Gregory CLEMENT]

Hi Maxime,

On 06/01/2015 16:28, Maxime Ripard wrote:
> 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>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory
> ---
>  arch/arm/boot/dts/armada-380.dtsi   | 2 +-
>  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 ++--
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/armada-380.dtsi b/arch/arm/boot/dts/armada-380.dtsi
> index 4173a8ab34e7..13400ce88c54 100644
> --- a/arch/arm/boot/dts/armada-380.dtsi
> +++ b/arch/arm/boot/dts/armada-380.dtsi
> @@ -32,7 +32,7 @@
>  
>  	soc {
>  		internal-regs {
> -			pinctrl {
> +			pinctrl at 18000 {
>  				compatible = "marvell,mv88f6810-pinctrl";
>  				reg = <0x18000 0x20>;
>  			};
> diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
> index 2aaa9d2ac284..212605ccc7b6 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 74391dace9e7..ada1f206028b 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";
> 


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

[PATCH v2 5/7] ARM: mvebu: A38x: Remove redundant pinctrl informations

[Gregory CLEMENT]

Hi Maxime,

On 06/01/2015 16:28, Maxime Ripard wrote:
> The compatible set in the armada-38x DTSI is always overridden, and the reg
> defined in there is duplicated in the armada-380 and armada-385 DTSIs.
> 
> Remove these useless items.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory
> ---
>  arch/arm/boot/dts/armada-380.dtsi | 1 -
>  arch/arm/boot/dts/armada-385.dtsi | 1 -
>  arch/arm/boot/dts/armada-38x.dtsi | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/armada-380.dtsi b/arch/arm/boot/dts/armada-380.dtsi
> index 13400ce88c54..7e509d2d74d0 100644
> --- a/arch/arm/boot/dts/armada-380.dtsi
> +++ b/arch/arm/boot/dts/armada-380.dtsi
> @@ -34,7 +34,6 @@
>  		internal-regs {
>  			pinctrl at 18000 {
>  				compatible = "marvell,mv88f6810-pinctrl";
> -				reg = <0x18000 0x20>;
>  			};
>  		};
>  
> diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
> index 5249a4d3c207..a54a252ddb4c 100644
> --- a/arch/arm/boot/dts/armada-385.dtsi
> +++ b/arch/arm/boot/dts/armada-385.dtsi
> @@ -39,7 +39,6 @@
>  		internal-regs {
>  			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 ada1f206028b..40200084c6c8 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -194,7 +194,6 @@
>  			};
>  
>  			pinctrl at 18000 {
> -				compatible = "marvell,mv88f6820-pinctrl";
>  				reg = <0x18000 0x20>;
>  			};
>  
> 


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

[PATCH v2 6/7] ARM: mvebu: Add a number of pinctrl functions

[Gregory CLEMENT]

Hi Maxime,

On 06/01/2015 16:28, Maxime Ripard wrote:
> Some pinctrl functions can be shared with all DTS out there, since they are
> generic, SoC-wide muxing options. Add a number of these to the DTSI to avoid
> duplication.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory
> ---
>  arch/arm/boot/dts/armada-38x.dtsi | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index 40200084c6c8..98885c58be29 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -195,6 +195,45 @@
>  
>  			pinctrl at 18000 {
>  				reg = <0x18000 0x20>;
> +
> +				ge0_rgmii_pins: ge-rgmii-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";
> +				};
> +
> +				mdio_pins: mdio-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";
> +				};
>  			};
>  
>  			gpio0: gpio at 18100 {
> 


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

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

[Gregory CLEMENT]

Hi Maxime,
[...]
> +				spi-flash at 0 {
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +					compatible = "st,m25p128";
> +					reg = <0>; /* Chip select 0 */
> +					spi-max-frequency = <108000000>;

The SPI flahs used on the AP board is the same that the one used on the GP board:
M25P128-VMF6P and the maximum frequency it can handle is 50MHz.

[...]

> +
> +			mdio at 72004 {
> +				pinctrl-names = <&mdio_pins>;
> +
> +				phy0: ethernet-phy at 0 {
Why don't you use the PHY address after the '@' ?
Here I expected something like
phy0: ethernet-phy at 1 {

> +					reg = <1>;
> +				};
> +
> +				phy1: ethernet-phy at 1 {
and here:
phy0: ethernet-phy at 6 {
> +					reg = <6>;
> +				};
> +
> +				phy2: ethernet-phy at 2 {
and here:
phy0: ethernet-phy at 4 {
> +					reg = <4>;
> +				};
> +			};


Thanks,

Gregory



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

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

[Maxime Ripard]

Hi,

On Tue, Jan 06, 2015 at 10:47:39PM +0100, Gregory CLEMENT wrote:
> > +				spi-flash at 0 {
> > +					#address-cells = <1>;
> > +					#size-cells = <1>;
> > +					compatible = "st,m25p128";
> > +					reg = <0>; /* Chip select 0 */
> > +					spi-max-frequency = <108000000>;
> 
> The SPI flahs used on the AP board is the same that the one used on the GP board:
> M25P128-VMF6P and the maximum frequency it can handle is 50MHz.

Actually, the one on the AP is a M25P128-VMF6PB, that has a max
frequency of 54MHz, but yeah, the frequency is wrong.

> > +
> > +			mdio at 72004 {
> > +				pinctrl-names = <&mdio_pins>;
> > +
> > +				phy0: ethernet-phy at 0 {
> Why don't you use the PHY address after the '@' ?
> Here I expected something like
> phy0: ethernet-phy at 1 {
> 
> > +					reg = <1>;
> > +				};
> > +
> > +				phy1: ethernet-phy at 1 {
> and here:
> phy0: ethernet-phy at 6 {
> > +					reg = <6>;
> > +				};
> > +
> > +				phy2: ethernet-phy at 2 {
> and here:
> phy0: ethernet-phy at 4 {

Indeed.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150107/cd05791e/attachment.sig>

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

[Maxime Ripard]

Hi,

On Tue, Jan 06, 2015 at 07:07:57PM +0100, Andrew Lunn wrote:
> > > Maybe add
> > > 
> > > stdout-path = &uart1;
> > 
> > Does that even work with the 8250? Last time I tried with a 3.18, it
> > didn't, and you still needed the console= bootargs.
> 
> It is for the bootloader, not Linux. barebox will use this, etc.  I
> think there are also plans for linux to use this. Not sure how far it
> has got.

Ok.

> > > > +			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>;
> > > > +			};
> > > 
> > > Is there anything on these two i2c busses?
> > 
> > One goes to some pin of the mPCIe slot, the other is connected to the
> > EEPROM.
> 
> So could you add the EEPROM, and a comment about the mPCIe slot?

I can't really add the EEPROM: it actually goes to two DIP sockets,
one of them holding that EEPROM, the other one being empty.

The default EEPROM also contains the board ID, that will be used by
the bootloader. Erasing this will result in a board that can't be
booted, so I'm not really sure exposing it to the user is a good idea.

> > > If not, why enable them and increase the clock speed?
> > 
> > The clock speed is not increased, it's actually the driver's default.
> 
> Dio you need this then? Is it in the dtsi file?

That got fixed recently by Chen-Yu, I guess we don't need it anymore.

> 
> > > > +			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";
> > > > +			};
> > > 
> > > If it is not obvious from the silk screen, could you describe which
> > > connector this uart is on, what pins are what?
> > 
> > There's two UART connectors documented in the user guide (JP8 and
> > JP9). UART1 is also connected to a FTDI chip, that is exposed through
> > a mini-USB connector.
> 
> I'm guessing the user guide is only available under NDA?

It appears so yes.

> Where as you can get the hardware without an NDA. At least i have a
> 370-rd, but no NDA. So some minimal documentation would be
> nice. Especially since it is backwards around to what most people
> would expect.

Ok, I'll add a comment.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150107/533dd591/attachment.sig>

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

[Andrew Lunn]

> > > > > +			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>;
> > > > > +			};
> > > > 
> > > > Is there anything on these two i2c busses?
> > > 
> > > One goes to some pin of the mPCIe slot, the other is connected to the
> > > EEPROM.
> > 
> > So could you add the EEPROM, and a comment about the mPCIe slot?
> 
> I can't really add the EEPROM: it actually goes to two DIP sockets,
> one of them holding that EEPROM, the other one being empty.
> 
> The default EEPROM also contains the board ID, that will be used by
> the bootloader. Erasing this will result in a board that can't be
> booted, so I'm not really sure exposing it to the user is a good idea.

O.K, please add a comment. People like me tend to run i2c-detect to
see if there is anything interesting on the bus. A warning you can
brick the board could save somebody an interesting time.

      Andrew

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

[Gregory CLEMENT]

Hi Maxime,
[..]

> +
> +			mdio at 72004 {
> +				pinctrl-names = <&mdio_pins>;
I guess it is a typo and you meant:

				pinctrl-names = "default;
				pinctrl-0 = <&mdio_pins>;


Gregory


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

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

[Gregory CLEMENT]

Hi Andrew, Maxime,

On 07/01/2015 15:34, Andrew Lunn wrote:
>>>>>> +			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>;
>>>>>> +			};
>>>>>
>>>>> Is there anything on these two i2c busses?
>>>>
>>>> One goes to some pin of the mPCIe slot, the other is connected to the
>>>> EEPROM.
>>>
>>> So could you add the EEPROM, and a comment about the mPCIe slot?

While trying to figure out how to do the muxing for the GP board I
looked at the AP board and actually the second i2c buse is not used
and even not muxed at all. The i2c pins are renamed many times in the
schematic so it was not easy to follow, but there is only one i2c bus
used on this board.

Gregory

>>
>> I can't really add the EEPROM: it actually goes to two DIP sockets,
>> one of them holding that EEPROM, the other one being empty.
>>
>> The default EEPROM also contains the board ID, that will be used by
>> the bootloader. Erasing this will result in a board that can't be
>> booted, so I'm not really sure exposing it to the user is a good idea.
> 
> O.K, please add a comment. People like me tend to run i2c-detect to
> see if there is anything interesting on the bus. A warning you can
> brick the board could save somebody an interesting time.
>
>       Andrew
> 


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

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

[Nadav Haklai]

-----Original Message-----
From: Maxime Ripard [mailto:maxime.ripard at free-electrons.com] 
Sent: Tuesday, January 06, 2015 7:31 PM
To: Andrew Lunn
Cc: Gregory Clement; Jason Cooper; Sebastian Hesselbarth; Linus Walleij; Thomas Petazzoni; linux-arm-kernel at lists.infradead.org; Tawfik Bayouk; Nadav Haklai; Lior Amsalem
Subject: Re: [PATCH v2 7/7] ARM: mvebu: Add Armada 385 Access Point Development Board support

Hi Andrew,

On Tue, Jan 06, 2015 at 04:57:05PM +0100, Andrew Lunn wrote:
> On Tue, Jan 06, 2015 at 04:28:20PM +0100, Maxime Ripard wrote:
> 
> Hi Maxime
> 
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-ap.dts
> > @@ -0,0 +1,140 @@
> > +/*
> > + * 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.
> > + */
> 
> Gregory is in the process of dual licensing some of the other mvebu DT 
> files. This one is single license. Should it be dual?

I'm not the original author though. Nadav, would you be ok to make a switch to a GPL/X11 dual-license?
[Nadav Haklai] Yes, I agree.

> > +
> > +/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";
> 
> Humm, ttyS0? Then why add the LL_DEBUG via UART1?

Yeah, my bad :)

It's obviously ttyS1

> Maybe add
> 
> stdout-path = &uart1;

Does that even work with the 8250? Last time I tried with a 3.18, it didn't, and you still needed the console= bootargs.

> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x00000000 0x80000000>; /* 2GB */
> > +	};
> > +
> > +	soc {
> > +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> > +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> > +
> > +		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>;
> > +			};
> 
> Is there anything on these two i2c busses?

One goes to some pin of the mPCIe slot, the other is connected to the EEPROM.

> If not, why enable them and increase the clock speed?

The clock speed is not increased, it's actually the driver's default.

> 
> > +			mdio at 72004 {
> > +				pinctrl-names = <&mdio_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";
> > +			};
> 
> If it is not obvious from the silk screen, could you describe which 
> connector this uart is on, what pins are what?

There's two UART connectors documented in the user guide (JP8 and JP9). UART1 is also connected to a FTDI chip, that is exposed through a mini-USB connector.

> > +
> > +			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";
> > +
> > +				/*
> > +				 * The Reference Clock 0 is used to
> > +				 * provide a clock to the PHY
> > +				 */
> 
> Does this clock need enabling? Should it be listed in the clocks 
> property?

>From what I understood, this clock is always running, it's just exposed to some external pin, and hence needs some muxing.

Maxime

Thanks,
Nadav