Skip to contentSkip to conversation

ARM: mvebu: Add Armada 385 AP support

PATCH Superseded Maxime Ripard 7 participants 17 messages Dec 5, 2014 – Jan 12, 2015

Subsystems (5)
Device tree bindings Arm (32-bit) Pin control Arm and arm64 SoC sub-architectures (common parts) +1 more subsystems

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Maxime Ripard

author
#0 lore raw

cover ARM: mvebu: Add Armada 385 AP support

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
Signature · 1 line
2.2.0
author
#1 lore raw

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

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 <[email protected]>
---
 arch/arm/Kconfig.debug | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
arch/arm/Kconfig.debug +9 -9
index d8f6a2ec3d4e..b0945d6b32b3 100644
@@ -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
Signature · 1 line
2.2.0
author
#2 lore raw

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

In reply to 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 <[email protected]>
---
 arch/arm/Kconfig.debug | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
arch/arm/Kconfig.debug +17 -0
index b0945d6b32b3..8f119f5ffcdd 100644
@@ -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
Signature · 1 line
2.2.0
#3 lore raw

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

Maxime,

Quoted 9 lines · 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 <[email protected]>
---
 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 <[email protected]>

thx,

Jason.

maintainer
#4 lore raw

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

Quoted 11 lines · On Friday 05 December 2014 10:25:03 Jason Cooper wrote:
Quoted 9 lines · 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 <[email protected]>
---
 arch/arm/Kconfig.debug | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
Quoted 7 lines

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 <[email protected]>

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

Arnd

author
#5 lore raw

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

In reply to 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 <[email protected]>
---
 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(-)
arch/arm/boot/dts/armada-385-db.dts +1 -1
index 1af886f1e486..d2ad03e08c17 100644
@@ -74,7 +74,7 @@
 				phy-mode = "rgmii-id";
 			};
 
-			mdio {
+			mdio at 72004 {
 				phy0: ethernet-phy at 0 {
 					reg = <0>;
 				};
arch/arm/boot/dts/armada-385-rd.dts +1 -1
index aaca2861dc87..74a3bfe6efd7 100644
@@ -67,7 +67,7 @@
 			};
 
 
-			mdio {
+			mdio at 72004 {
 				phy0: ethernet-phy at 0 {
 					reg = <0>;
 				};
arch/arm/boot/dts/armada-385.dtsi +1 -1
index 6283d7912f71..5249a4d3c207 100644
@@ -37,7 +37,7 @@
 
 	soc {
 		internal-regs {
-			pinctrl {
+			pinctrl at 18000 {
 				compatible = "marvell,mv88f6820-pinctrl";
 				reg = <0x18000 0x20>;
 			};
arch/arm/boot/dts/armada-38x.dtsi +2 -2
index 242d0ecc99f3..221cca4e79fc 100644
@@ -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";
Signature · 1 line
2.2.0
author
#6 lore raw

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

In reply to 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 <[email protected]>
---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/pinctrl/mvebu/pinctrl-armada-38x.c +4 -2
index 1049f82fb62f..fd743fab07f5 100644
@@ -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),
Signature · 1 line
2.2.0
#7 lore raw

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

Quoted 9 lines · 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 <[email protected]>
---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Acked-by Jason Cooper <[email protected]>

thx,

Jason.

#9 lore raw

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

Quoted 11 lines · Linus Walleij
Quoted 6 lines · 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 <[email protected]>

Patch applied with Jason's ACK.

I did?

thx,

Jason.

#10 lore raw

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

Quoted 7 lines · Jason Cooper
Quoted 6 lines · Linus Walleij
Quoted 3 lines · Maxime Ripard

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

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Add this case to the pinctrl driver.

Signed-off-by Maxime Ripard <[email protected]>

Patch applied with Jason's ACK.

I did?

Yeah...

Date: Fri, 5 Dec 2014 10:26:26 -0500
From: Jason Cooper <[email protected]>
To: Maxime Ripard <[email protected]>
Cc: Gregory Clement <[email protected]>,
Andrew Lunn <[email protected]>,
Sebastian Hesselbarth <[email protected]>,
Linus Walleij <[email protected]>,
Thomas Petazzoni <[email protected]>,
linux-arm-kernel at lists.infradead.org,
Tawfik Bayouk <[email protected]>,
Nadav Haklai <[email protected]>, Lior Amsalem <[email protected]>
Subject: Re: [PATCH 4/5] pinctrl: mvebu: a38x: Add UART1 muxing options
Message-ID: <[email protected]>
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)

Quoted 9 lines · 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 <[email protected]>
---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Acked-by Jason Cooper <[email protected]>

thx,

Jason.

Yours,
Linus Walleij

#11 lore raw

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

Quoted 12 lines · Linus Walleij
Quoted 11 lines · Jason Cooper
Quoted 10 lines · Linus Walleij
Quoted 6 lines · 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 <[email protected]>
Quoted 7 lines
Quoted 3 lines
Quoted 1 line

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.

author
#12 lore raw

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

In reply to 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 <[email protected]>
---
 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
arch/arm/boot/dts/Makefile +1 -0
index 38c89cafa1ab..363fdeaa0368 100644
@@ -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) += \
arch/arm/boot/dts/armada-385-ap.dts new file +200 -0

200 lines not on this page · raw message

Signature · 1 line
2.2.0
maintainer
#13 lore raw

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

arch/arm/boot/dts/armada-385-ap.dts line 25

Quoted 3 lines · On Friday 05 December 2014 15:44:58 Maxime Ripard wrote:
arch/arm/boot/dts/armada-385-ap.dts new file +3 -0
+       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

#14 lore raw

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

In reply to Maxime Ripard

Dear Maxime Ripard,

arch/arm/boot/dts/armada-385-ap.dts line 38

Quoted 7 lines · Maxime Ripard
arch/arm/boot/dts/armada-385-ap.dts new file +7 -0
+	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.

arch/arm/boot/dts/armada-385-ap.dts line 68

Quoted 2 lines
arch/arm/boot/dts/armada-385-ap.dts new file +2 -0
+			mdio at 72004 {
+				pinctrl-names = <&phy_pins>;

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

arch/arm/boot/dts/armada-385-ap.dts line 102

Quoted 8 lines
arch/arm/boot/dts/armada-385-ap.dts new file +8 -0
+			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.

arch/arm/boot/dts/armada-385-ap.dts line 107

Quoted 4 lines
arch/arm/boot/dts/armada-385-ap.dts new file +4 -0
+				i2c0_pins: i2c-pins-0 {
+					marvell,pins = "mpp2", "mpp3";
+					marvell,function = "i2c0";
+				};

Same question here, maybe define it in .dtsi ?

arch/arm/boot/dts/armada-385-ap.dts line 112

Quoted 5 lines
arch/arm/boot/dts/armada-385-ap.dts new file +5 -0
+
+				phy_pins: phy-pins {
+					marvell,pins = "mpp4", "mpp5";
+					marvell,function = "ge";
+				};

Same here.

Quoted 33 lines
arch/arm/boot/dts/armada-385-ap.dts new file +33 -0
+
+				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";
+			};

arch/arm/boot/dts/armada-385-ap.dts line 155

Quoted 10 lines
arch/arm/boot/dts/armada-385-ap.dts new file +10 -0
+
+			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.

arch/arm/boot/dts/armada-385-ap.dts line 163

Quoted 8 lines
arch/arm/boot/dts/armada-385-ap.dts new file +8 -0
+				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?

arch/arm/boot/dts/armada-385-ap.dts line 170

Quoted 7 lines
arch/arm/boot/dts/armada-385-ap.dts new file +7 -0
+		};
+
+		pcie-controller {
+			status = "okay";
+			/*
+			 * The two PCIe units are accessible through
+			 * standard PCIe slots on the board.

Two, or three ? :-)

Quoted 19 lines
arch/arm/boot/dts/armada-385-ap.dts new file +19 -0
+			 */
+			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 {

arch/arm/boot/dts/armada-385-ap.dts line 199

Quoted 10 lines
arch/arm/boot/dts/armada-385-ap.dts new file +10 -0
+		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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#15 lore raw

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

Hi Maxime,

[...]

Quoted 9 lines

arch/arm/boot/dts/armada-385-ap.dts line 170

Quoted 7 lines
arch/arm/boot/dts/armada-385-ap.dts new file +7 -0
+		};
+
+		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.

Quoted 39 lines
Quoted 20 lines
arch/arm/boot/dts/armada-385-ap.dts new file +19 -0
+			 */
+			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 {

arch/arm/boot/dts/armada-385-ap.dts line 199

Quoted 10 lines
arch/arm/boot/dts/armada-385-ap.dts new file +10 -0
+		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

Signature · 4 lines
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
maintainer
#16 lore raw

cover ARM: mvebu: Add Armada 385 AP support

In reply to Maxime Ripard
Quoted 6 lines · 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.

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

Quoted 24 lines

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
Signature · 1 line
2.2.0