[PATCH RFC] ARM: dts: add support for Turris Omnia

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---

Hello,

the following components are working:

 - WAN port
 - eMMC
 - UART0
 - USB

Still missing is support for the switch. Wireless fails to probe, didn't
debug this up to now. SFP is untested as is UART1.

The device tree on the device doesn't specify a board compatible, I added
"turris,omnia". Do I need to "register" turris in vendor-prefixes.txt for that?
@Tomas+Martin: Is this correct at all, or should I better reference cz.nic?

Best regards
Uwe

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 246 ++++++++++++++++++++++++++
 2 files changed, 247 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..d3cd8a4d713d
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,246 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe@kleine-koenig.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+	model = "Turris Omnia";
+	compatible = "turris,omnia", "marvell,armada385", "marvell,armada380";
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+		internal-regs {
+
+			/* USB part of the eSATA/USB 2.0 port */
+			usb@58000 {
+				status = "okay";
+			};
+
+			sata@a8000 {
+				status = "okay";
+			};
+
+			sdhci@d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3@f0000 {
+				status = "okay";
+			};
+
+			usb3@f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie@1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@2,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@3,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
+
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux@70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";
+
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			status = "okay";
+
+			/* STM32F0 at address 0x2a */
+			/* leds device at address 0x2b */
+
+			eeprom@54 {
+				/* holds configuration about RAM, evaluated by bootloader */
+				compatible = "at,24c64";
+				reg = <0x54>;
+			};
+		};
+
+		i2c@5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+
+			/* ATSHA204A at address 0x64 */
+		};
+
+		i2c@6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			/* exposed on pin header */
+		};
+	};
+};
+
+&mdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy@1 {
+		status = "okay";
+		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&pinctrl {
+	spi0cs1_pins: spi0-pins-0cs1 {
+		marvell,pins = "mpp26";
+		marvell,function = "spi0";
+	};
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+	status = "okay";
+
+	spi-nor@0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition@0 {
+			reg = <0x0 0x00100000>;
+			label = "U-Boot";
+		};
+
+		partition@1 {
+			reg = <0x00100000 0x00700000>;
+			label = "Rescue system";
+		};
+	};
+
+	/* @1 is on pin header */
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+	status = "okay";
+};
-- 
2.10.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.

Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---

Hello,

the following components are working:

 - WAN port
 - eMMC
 - UART0
 - USB

Still missing is support for the switch. Wireless fails to probe, didn't
debug this up to now. SFP is untested as is UART1.

The device tree on the device doesn't specify a board compatible, I added
"turris,omnia". Do I need to "register" turris in vendor-prefixes.txt for that?
@Tomas+Martin: Is this correct at all, or should I better reference cz.nic?

Best regards
Uwe

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 246 ++++++++++++++++++++++++++
 2 files changed, 247 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..d3cd8a4d713d
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,246 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+	model = "Turris Omnia";
+	compatible = "turris,omnia", "marvell,armada385", "marvell,armada380";
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+		internal-regs {
+
+			/* USB part of the eSATA/USB 2.0 port */
+			usb at 58000 {
+				status = "okay";
+			};
+
+			sata at a8000 {
+				status = "okay";
+			};
+
+			sdhci at d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3 at f0000 {
+				status = "okay";
+			};
+
+			usb3 at f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 2,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 3,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
+
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux at 70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";
+
+		i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			status = "okay";
+
+			/* STM32F0 at address 0x2a */
+			/* leds device at address 0x2b */
+
+			eeprom at 54 {
+				/* holds configuration about RAM, evaluated by bootloader */
+				compatible = "at,24c64";
+				reg = <0x54>;
+			};
+		};
+
+		i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+
+			/* ATSHA204A at address 0x64 */
+		};
+
+		i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			/* exposed on pin header */
+		};
+	};
+};
+
+&mdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy at 1 {
+		status = "okay";
+		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&pinctrl {
+	spi0cs1_pins: spi0-pins-0cs1 {
+		marvell,pins = "mpp26";
+		marvell,function = "spi0";
+	};
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+	status = "okay";
+
+	spi-nor at 0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition at 0 {
+			reg = <0x0 0x00100000>;
+			label = "U-Boot";
+		};
+
+		partition at 1 {
+			reg = <0x00100000 0x00700000>;
+			label = "Rescue system";
+		};
+	};
+
+	/* @1 is on pin header */
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+	status = "okay";
+};
-- 
2.10.2

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +	status = "okay";
> +
> +	phy1: phy@1 {
> +		status = "okay";
> +		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};

phy.txt says:

- compatible: Compatible list, may contain
  "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
  PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
  specifications. If neither of these are specified, the default is to
  assume clause 22.

  If the phy's identifier is known then the list may contain an entry
  of the form: "ethernet-phy-idAAAA.BBBB" where
     AAAA - The value of the 16 bit Phy Identifier 1 register as
            4 hex digits. This is the chip vendor OUI bits 3:18
     BBBB - The value of the 16 bit Phy Identifier 2 register as
            4 hex digits. This is the chip vendor OUI bits 19:24,
            followed by 10 bits of a vendor specific ID.

  The compatible list should not contain other values than those
  listed here.

Please don't list the "marvell,*" names.

       Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +	status = "okay";
> +
> +	phy1: phy at 1 {
> +		status = "okay";
> +		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};

phy.txt says:

- compatible: Compatible list, may contain
  "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
  PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
  specifications. If neither of these are specified, the default is to
  assume clause 22.

  If the phy's identifier is known then the list may contain an entry
  of the form: "ethernet-phy-idAAAA.BBBB" where
     AAAA - The value of the 16 bit Phy Identifier 1 register as
            4 hex digits. This is the chip vendor OUI bits 3:18
     BBBB - The value of the 16 bit Phy Identifier 2 register as
            4 hex digits. This is the chip vendor OUI bits 19:24,
            followed by 10 bits of a vendor specific ID.

  The compatible list should not contain other values than those
  listed here.

Please don't list the "marvell,*" names.

       Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Sat, Nov 05, 2016 at 10:04:41PM +0100, Andrew Lunn wrote:
> > +&mdio {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&mdio_pins>;
> > +	status = "okay";
> > +
> > +	phy1: phy@1 {
> > +		status = "okay";
> > +		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
> > +		reg = <1>;
> > +	};
> 
> phy.txt says:
> 
> - compatible: Compatible list, may contain
>   "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
>   PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
>   specifications. If neither of these are specified, the default is to
>   assume clause 22.
> 
>   If the phy's identifier is known then the list may contain an entry
>   of the form: "ethernet-phy-idAAAA.BBBB" where
>      AAAA - The value of the 16 bit Phy Identifier 1 register as
>             4 hex digits. This is the chip vendor OUI bits 3:18
>      BBBB - The value of the 16 bit Phy Identifier 2 register as
>             4 hex digits. This is the chip vendor OUI bits 19:24,
>             followed by 10 bits of a vendor specific ID.
> 
>   The compatible list should not contain other values than those
>   listed here.
> 
> Please don't list the "marvell,*" names.

Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this
regard, too.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

On Sat, Nov 05, 2016 at 10:04:41PM +0100, Andrew Lunn wrote:
> > +&mdio {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&mdio_pins>;
> > +	status = "okay";
> > +
> > +	phy1: phy at 1 {
> > +		status = "okay";
> > +		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
> > +		reg = <1>;
> > +	};
> 
> phy.txt says:
> 
> - compatible: Compatible list, may contain
>   "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
>   PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
>   specifications. If neither of these are specified, the default is to
>   assume clause 22.
> 
>   If the phy's identifier is known then the list may contain an entry
>   of the form: "ethernet-phy-idAAAA.BBBB" where
>      AAAA - The value of the 16 bit Phy Identifier 1 register as
>             4 hex digits. This is the chip vendor OUI bits 3:18
>      BBBB - The value of the 16 bit Phy Identifier 2 register as
>             4 hex digits. This is the chip vendor OUI bits 19:24,
>             followed by 10 bits of a vendor specific ID.
> 
>   The compatible list should not contain other values than those
>   listed here.
> 
> Please don't list the "marvell,*" names.

Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this
regard, too.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161105/813ef036/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this
> regard, too.

There is a whitelist of compatible strings which are ignored, for
backwards compatibility. See of_mdiobus_child_is_phy(). It would be
nice to fix keystone, but it is not required.

     Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this
> regard, too.

There is a whitelist of compatible strings which are ignored, for
backwards compatibility. See of_mdiobus_child_is_phy(). It would be
nice to fix keystone, but it is not required.

     Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Still missing is support for the switch.

Is it a Marvell Switch? armada-370-rd.dts would be a good start for
the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

> SFP is untested as is UART1.

UART would be unusual. They are normally i2c.

> Do I need to "register" turris in vendor-prefixes.txt for that?

Yes please.

    Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Still missing is support for the switch.

Is it a Marvell Switch? armada-370-rd.dts would be a good start for
the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

> SFP is untested as is UART1.

UART would be unusual. They are normally i2c.

> Do I need to "register" turris in vendor-prefixes.txt for that?

Yes please.

    Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Hello Andrew,

On Sat, Nov 05, 2016 at 10:23:26PM +0100, Andrew Lunn wrote:
> > Still missing is support for the switch.
> 
> Is it a Marvell Switch? armada-370-rd.dts would be a good start for
> the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

Yeah, a 88E6176. I already try to understand vf610-zii-dev-rev-b.dts. Do
you know if this driver works for the 88E6176?

> > SFP is untested as is UART1.
> 
> UART would be unusual. They are normally i2c.

I wanted to say: SFP is untested, and UART1 is untested too. Yes, SFP is
connected via i2c.

> > Do I need to "register" turris in vendor-prefixes.txt for that?
> 
> Yes please.

OK, will wait for Martin to comment what we want there. cznic or turris.

Thanks
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

Hello Andrew,

On Sat, Nov 05, 2016 at 10:23:26PM +0100, Andrew Lunn wrote:
> > Still missing is support for the switch.
> 
> Is it a Marvell Switch? armada-370-rd.dts would be a good start for
> the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

Yeah, a 88E6176. I already try to understand vf610-zii-dev-rev-b.dts. Do
you know if this driver works for the 88E6176?

> > SFP is untested as is UART1.
> 
> UART would be unusual. They are normally i2c.

I wanted to say: SFP is untested, and UART1 is untested too. Yes, SFP is
connected via i2c.

> > Do I need to "register" turris in vendor-prefixes.txt for that?
> 
> Yes please.

OK, will wait for Martin to comment what we want there. cznic or turris.

Thanks
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161105/7d3c829b/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

On Sat, Nov 05, 2016 at 10:27:49PM +0100, Uwe Kleine-König wrote:
> Hello Andrew,
> 
> On Sat, Nov 05, 2016 at 10:23:26PM +0100, Andrew Lunn wrote:
> > > Still missing is support for the switch.
> > 
> > Is it a Marvell Switch? armada-370-rd.dts would be a good start for
> > the old binding? vf610-zii-dev-rev-b.dts uses the new binding.
> 
> Yeah, a 88E6176. I already try to understand vf610-zii-dev-rev-b.dts. Do
> you know if this driver works for the 88E6176?

Yes it does. 

The vf610-zii-dev-rev-b is a bit complex because it has three
switches, and an mdio mux. You should be able to transplant the
switch0: switch0@0 part into the mdio node.

	 Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

On Sat, Nov 05, 2016 at 10:27:49PM +0100, Uwe Kleine-K?nig wrote:
> Hello Andrew,
> 
> On Sat, Nov 05, 2016 at 10:23:26PM +0100, Andrew Lunn wrote:
> > > Still missing is support for the switch.
> > 
> > Is it a Marvell Switch? armada-370-rd.dts would be a good start for
> > the old binding? vf610-zii-dev-rev-b.dts uses the new binding.
> 
> Yeah, a 88E6176. I already try to understand vf610-zii-dev-rev-b.dts. Do
> you know if this driver works for the 88E6176?

Yes it does. 

The vf610-zii-dev-rev-b is a bit complex because it has three
switches, and an mdio mux. You should be able to transplant the
switch0: switch0 at 0 part into the mdio node.

	 Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

Hello,

I just noticed that I dropped the other recipents from the conversation.
I readded them also adding some context.

> > On Sun, Nov 06, 2016 at 05:28:09PM +0100, Andrew Lunn wrote:
> > > On Sun, Nov 06, 2016 at 11:45:34AM +0100, Uwe Kleine-König wrote:
> > > > +     switch@0 {
> > > > +             compatible = "marvell,mv88e6176", "marvell,mv88e6085";
> > > 
> > > All currently supported switches are compatible with the mv88e6085, in
> > > terms of probing. During the probe it can read an ID register to find
> > > out what specific switch it is, so you don't need additional details
> > > here. So please drop the marvell,mv88e6176, it will never be used.
> > 
> > That's what I know from several imx devices, for example look at
> > 
> > $ git grep imx25 arch/arm/boot/dts/imx25.dtsi
> > 
> > There are several instances of imx25-something,
> > imx$earliersoc-something. Given there is a good reason for this, I
> > wonder why it's different here.
> 
> Possibly because you cannot easily tell the variants apart using ID
> registers in the devices register space? For the switch it is very
> easy, port register 3 is the ID. It only becomes an issue when probe
> cannot find this register. There is a new generation mv88e6390 which
> i'm currently adding support for which has moved the port
> registers. So i need to add a new compatible string so probe knows
> where to look.

Even if you cannot easily distinguish between an "fsl,imx35-cspi" and an
"fsl,imx27-cspi" by inspecting hardware registers, it would be enough to
write in imx25.dtsi

	compatible = "fsl,imx35-cspi";

still we're writing

	compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";

because it never hurts and is helpful when later some differences are
found and it documents the situation more accurately.

I wonder what the dt people have to say here.

> > > From what you say here, the switch is in mulit-chip mode, at address
> > > 0x10. So set the reg property to <0x10>.
> > 
> > When using 0x10 I get
> > 
> > 	mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
> 
> Great.
> 
> > 
> > so now I have to find out how to use this.
> 
> Just use them as normal interfaces. ip addr add 10.42.42.42/24 dev
> lan4, brctrl addif br0 lan2, ethtool -S lan1 etc.
> 
> The whole idea is that they are just normal Linux network interfaces.

That's how I expected things to be, but

	uwe@omnia:~$ dmesg | tail
	...
	[ 2164.644589] libphy: mdio_driver_register: mv88e6085
	[ 2164.649823] mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
	uwe@omnia:~$ ls /sys/class/net/
	eth0  eth1  eth2  lo

there are no additional interfaces. I will debug a bit further.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

Hello,

I just noticed that I dropped the other recipents from the conversation.
I readded them also adding some context.

> > On Sun, Nov 06, 2016 at 05:28:09PM +0100, Andrew Lunn wrote:
> > > On Sun, Nov 06, 2016 at 11:45:34AM +0100, Uwe Kleine-K?nig wrote:
> > > > +     switch at 0 {
> > > > +             compatible = "marvell,mv88e6176", "marvell,mv88e6085";
> > > 
> > > All currently supported switches are compatible with the mv88e6085, in
> > > terms of probing. During the probe it can read an ID register to find
> > > out what specific switch it is, so you don't need additional details
> > > here. So please drop the marvell,mv88e6176, it will never be used.
> > 
> > That's what I know from several imx devices, for example look at
> > 
> > $ git grep imx25 arch/arm/boot/dts/imx25.dtsi
> > 
> > There are several instances of imx25-something,
> > imx$earliersoc-something. Given there is a good reason for this, I
> > wonder why it's different here.
> 
> Possibly because you cannot easily tell the variants apart using ID
> registers in the devices register space? For the switch it is very
> easy, port register 3 is the ID. It only becomes an issue when probe
> cannot find this register. There is a new generation mv88e6390 which
> i'm currently adding support for which has moved the port
> registers. So i need to add a new compatible string so probe knows
> where to look.

Even if you cannot easily distinguish between an "fsl,imx35-cspi" and an
"fsl,imx27-cspi" by inspecting hardware registers, it would be enough to
write in imx25.dtsi

	compatible = "fsl,imx35-cspi";

still we're writing

	compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";

because it never hurts and is helpful when later some differences are
found and it documents the situation more accurately.

I wonder what the dt people have to say here.

> > > From what you say here, the switch is in mulit-chip mode, at address
> > > 0x10. So set the reg property to <0x10>.
> > 
> > When using 0x10 I get
> > 
> > 	mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
> 
> Great.
> 
> > 
> > so now I have to find out how to use this.
> 
> Just use them as normal interfaces. ip addr add 10.42.42.42/24 dev
> lan4, brctrl addif br0 lan2, ethtool -S lan1 etc.
> 
> The whole idea is that they are just normal Linux network interfaces.

That's how I expected things to be, but

	uwe at omnia:~$ dmesg | tail
	...
	[ 2164.644589] libphy: mdio_driver_register: mv88e6085
	[ 2164.649823] mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
	uwe at omnia:~$ ls /sys/class/net/
	eth0  eth1  eth2  lo

there are no additional interfaces. I will debug a bit further.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/854a7843/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Martin Strbačka]

[-- Attachment #1.1.1: Type: text/plain, Size: 388 bytes --]

On 5.11.2016 22:27, Uwe Kleine-König wrote:
>>> Do I need to "register" turris in vendor-prefixes.txt for that?
>> > 
>> > Yes please.
> OK, will wait for Martin to comment what we want there. cznic or turris.

Hello,

please use CZ.NIC in this case. Turris Omnia is a model name.

Thanks for your work!

Martin
-- 
Martin Strbacka CZ.NIC, z.s.p.o. tel. +420 604 217 854


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Martin Strbačka]

On 5.11.2016 22:27, Uwe Kleine-K?nig wrote:
>>> Do I need to "register" turris in vendor-prefixes.txt for that?
>> > 
>> > Yes please.
> OK, will wait for Martin to comment what we want there. cznic or turris.

Hello,

please use CZ.NIC in this case. Turris Omnia is a model name.

Thanks for your work!

Martin
-- 
Martin Strbacka CZ.NIC, z.s.p.o. tel. +420 604 217 854

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/cee2ad06/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek-x+rMaJPWets]

Hello Uwe and all!

On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-König 
<uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
> 
> Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> ---
> 
> Hello,
> 
> the following components are working:
> 
>  - WAN port
>  - eMMC

But I not not sure about DDR50 mode. At least with kernel 4.4, that we 
use in production, we had to limit to SDR50 to overcome I/O errors and 
communication instability, if I can remember it correctly. So it might 
need more testing with the current kernel.

> 
>  - UART0
>  - USB

It is worth noting that the USB 2.0 interface of Armada 385 is wired to 
USB pinout of the last (right-most) PCIe connector. The two USB3 
interfaces routed through SERDES 1 and 3 go directly to the external 
USB connectors.

> 
> Still missing is support for the switch. Wireless fails to probe, 
> didn't
> debug this up to now. SFP is untested as is UART1.

Actually SFP is connected to SGMII interface of eth1, which is routed 
through SERDES 5. The SGMII line is shared between the SFP and metallic 
PHY 88E1514. There is a autonomous high-speed switch connected to the 
SFPDET signal from SFP cage. It disconnects the metallic SFP and 
connects SGMII to SFP once the module is connected.

The SFP is also connected to the I2C mux port 4 and to GPIO expander 
for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:

&i2c0 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c0_pins>;
        status = "okay";
        clock-frequency = <100000>;

        i2cmux@70 {
                compatible = "nxp,pca9547";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x70>;
                status = "okay";

...

                i2c@7 {
                        /* SFP+ GPIO expander */
                        #address-cells = <1>;
                        #size-cells = <0>;
                        reg = <7>;

                        sfpgpio: gpio@71 {
                                compatible = "nxp,pca9538";
                                reg = <0x71>;
                                interrupt-parent = <&gpio1>;
                                interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
                                gpio-controller;
                                #gpio-cells = <2>;
                        };
                };
	};
};

We have our proprietary support hacked onto mvneta driver for 
disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore 
SFP in this DTS altogether and let's wait till "phylink based SFP 
module support" or something alike hits upstream, so we can base the 
SFP support on solid code; unless somebody has a better idea, of course.

> 
> 
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts 
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..d3cd8a4d713d
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,246 @@
...
> +
> +			/* USB part of the eSATA/USB 2.0 port */

This comment is perhaps some error inherited from my development DTS. 
We do not have any eSATA, perhaps PCIe/USB 2.0 slot.

> 
> +			usb@58000 {
> +				status = "okay";
> +			};
> +
> +
> +&eth0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge0_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +&eth1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge1_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 
switch. The problem is that from what I have read so far the switch can 
not operate in DSA mode with two CPU ports. We currently operate the 
switch in "normal mode" with the eth0 and eth1 set to fixed-link 
1000/full and with proprietary driver (derived from OpenWRT switch 
drivers). I would say that these records for eth0 and eth1 are 
therefore redundant, because it does nothing without the switch support 
and it would most likely change once we have DSA driver (using only 
eth0).

Tomas

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hello Uwe and all!

On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig 
<uwe@kleine-koenig.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
> 
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
> 
> Hello,
> 
> the following components are working:
> 
>  - WAN port
>  - eMMC

But I not not sure about DDR50 mode. At least with kernel 4.4, that we 
use in production, we had to limit to SDR50 to overcome I/O errors and 
communication instability, if I can remember it correctly. So it might 
need more testing with the current kernel.

> 
>  - UART0
>  - USB

It is worth noting that the USB 2.0 interface of Armada 385 is wired to 
USB pinout of the last (right-most) PCIe connector. The two USB3 
interfaces routed through SERDES 1 and 3 go directly to the external 
USB connectors.

> 
> Still missing is support for the switch. Wireless fails to probe, 
> didn't
> debug this up to now. SFP is untested as is UART1.

Actually SFP is connected to SGMII interface of eth1, which is routed 
through SERDES 5. The SGMII line is shared between the SFP and metallic 
PHY 88E1514. There is a autonomous high-speed switch connected to the 
SFPDET signal from SFP cage. It disconnects the metallic SFP and 
connects SGMII to SFP once the module is connected.

The SFP is also connected to the I2C mux port 4 and to GPIO expander 
for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:

&i2c0 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c0_pins>;
        status = "okay";
        clock-frequency = <100000>;

        i2cmux at 70 {
                compatible = "nxp,pca9547";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x70>;
                status = "okay";

...

                i2c at 7 {
                        /* SFP+ GPIO expander */
                        #address-cells = <1>;
                        #size-cells = <0>;
                        reg = <7>;

                        sfpgpio: gpio at 71 {
                                compatible = "nxp,pca9538";
                                reg = <0x71>;
                                interrupt-parent = <&gpio1>;
                                interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
                                gpio-controller;
                                #gpio-cells = <2>;
                        };
                };
	};
};

We have our proprietary support hacked onto mvneta driver for 
disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore 
SFP in this DTS altogether and let's wait till "phylink based SFP 
module support" or something alike hits upstream, so we can base the 
SFP support on solid code; unless somebody has a better idea, of course.

> 
> 
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts 
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..d3cd8a4d713d
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,246 @@
...
> +
> +			/* USB part of the eSATA/USB 2.0 port */

This comment is perhaps some error inherited from my development DTS. 
We do not have any eSATA, perhaps PCIe/USB 2.0 slot.

> 
> +			usb at 58000 {
> +				status = "okay";
> +			};
> +
> +
> +&eth0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge0_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +&eth1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge1_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 
switch. The problem is that from what I have read so far the switch can 
not operate in DSA mode with two CPU ports. We currently operate the 
switch in "normal mode" with the eth0 and eth1 set to fixed-link 
1000/full and with proprietary driver (derived from OpenWRT switch 
drivers). I would say that these records for eth0 and eth1 are 
therefore redundant, because it does nothing without the switch support 
and it would most likely change once we have DSA driver (using only 
eth0).

Tomas

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.

You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?

> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;

It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.

> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.

Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.

	Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.

You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?

> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;

It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.

> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.

Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.

	Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek]

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

Hi Andrew!

On Mon, Nov 14, 2016 at 2:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  Actually SFP is connected to SGMII interface of eth1, which is
>>  routed through SERDES 5.
> 
> You say eth1 here. Yet lower down you say got eth0 and eth1 are
> connected to the switch?

Oh sorry, this was a NIC name based on probing order derived from base 
address of NIC registers:

	eth1: ethernet@30000 - probes as eth0
	eth2: ethernet@34000 - probes as eth1
	eth0: ethernet@70000 - probes as eth2

It is a bit confusing. I meant eth2 in DTS. Sorry.

> 
> 
>>  We have our proprietary support hacked onto mvneta driver for
>>  disconnecting PHY on the fly. It is a bit nasty, so I suggest to
>>  ignore SFP in this DTS altogether and let's wait till "phylink based
>>  SFP module support" or something alike hits upstream, so we can base
>>  the SFP support on solid code;
> 
> It would be great if you could work on getting the phylink patches
> into mainline. It is something i have wanted to do for a long time,
> but it is too low down on my priority list to get to. The code is high
> quality, so i don't think there will be too many issues. It probably
> just needs splitting up into smaller batches, submitting, and working
> on any comments.

That is exactly what I thought when I saw the patches for the first 
time. I will try to merge the patches to the current kernel and see 
what happens. I still need to learn a lot about PHY subsystem.

> 
> 
>>  Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
>>  switch. The problem is that from what I have read so far the switch
>>  can not operate in DSA mode with two CPU ports.
> 
> Again, this is something i wanted to do, and i did have a prototype at
> one point. But again, not enough time. If you have resources to work
> on this, i can find my code, explain my ideas, and let you complete
> it.

I am definitely interested, though I didn't have time to read and 
absorb DSA yet, but I definitely want to try to hack 88E6176 support. I 
would be really grateful if you can provide some pointers and/or code 
to start from.

Thanks,
Tomas



[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek]

Hi Andrew!

(Sorry for re-posting the previous e-mail, that most likely didn't get 
through.)

On Mon, Nov 14, 2016 at 2:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  Actually SFP is connected to SGMII interface of eth1, which is
>>  routed through SERDES 5.
> 
> You say eth1 here. Yet lower down you say got eth0 and eth1 are
> connected to the switch?

Oh sorry, this was a NIC name based on probing order derived from base 
address of NIC registers:

	eth1: ethernet@30000 - probes as eth0
	eth2: ethernet@34000 - probes as eth1
	eth0: ethernet@70000 - probes as eth2

It is a bit confusing. I meant eth2 in DTS. Sorry.

> 
> 
>>  We have our proprietary support hacked onto mvneta driver for
>>  disconnecting PHY on the fly. It is a bit nasty, so I suggest to
>>  ignore SFP in this DTS altogether and let's wait till "phylink based
>>  SFP module support" or something alike hits upstream, so we can base
>>  the SFP support on solid code;
> 
> It would be great if you could work on getting the phylink patches
> into mainline. It is something i have wanted to do for a long time,
> but it is too low down on my priority list to get to. The code is high
> quality, so i don't think there will be too many issues. It probably
> just needs splitting up into smaller batches, submitting, and working
> on any comments.

That is exactly what I thought when I saw the patches for the first 
time. I will try to merge the patches to the current kernel and see 
what happens. I still need to learn a lot about PHY subsystem.

> 
> 
>>  Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
>>  switch. The problem is that from what I have read so far the switch
>>  can not operate in DSA mode with two CPU ports.
> 
> Again, this is something i wanted to do, and i did have a prototype at
> one point. But again, not enough time. If you have resources to work
> on this, i can find my code, explain my ideas, and let you complete
> it.

I am definitely interested, though I didn't have time to read and 
absorb DSA yet, but I definitely want to try to hack 88E6176 support. I 
would be really grateful if you can provide some pointers and/or code 
to start from.

Thanks,
Tomas

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hi Andrew!

(Sorry for re-posting the previous e-mail, that most likely didn't get 
through.)

On Mon, Nov 14, 2016 at 2:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  Actually SFP is connected to SGMII interface of eth1, which is
>>  routed through SERDES 5.
> 
> You say eth1 here. Yet lower down you say got eth0 and eth1 are
> connected to the switch?

Oh sorry, this was a NIC name based on probing order derived from base 
address of NIC registers:

	eth1: ethernet at 30000 - probes as eth0
	eth2: ethernet at 34000 - probes as eth1
	eth0: ethernet at 70000 - probes as eth2

It is a bit confusing. I meant eth2 in DTS. Sorry.

> 
> 
>>  We have our proprietary support hacked onto mvneta driver for
>>  disconnecting PHY on the fly. It is a bit nasty, so I suggest to
>>  ignore SFP in this DTS altogether and let's wait till "phylink based
>>  SFP module support" or something alike hits upstream, so we can base
>>  the SFP support on solid code;
> 
> It would be great if you could work on getting the phylink patches
> into mainline. It is something i have wanted to do for a long time,
> but it is too low down on my priority list to get to. The code is high
> quality, so i don't think there will be too many issues. It probably
> just needs splitting up into smaller batches, submitting, and working
> on any comments.

That is exactly what I thought when I saw the patches for the first 
time. I will try to merge the patches to the current kernel and see 
what happens. I still need to learn a lot about PHY subsystem.

> 
> 
>>  Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
>>  switch. The problem is that from what I have read so far the switch
>>  can not operate in DSA mode with two CPU ports.
> 
> Again, this is something i wanted to do, and i did have a prototype at
> one point. But again, not enough time. If you have resources to work
> on this, i can find my code, explain my ideas, and let you complete
> it.

I am definitely interested, though I didn't have time to read and 
absorb DSA yet, but I definitely want to try to hack 88E6176 support. I 
would be really grateful if you can provide some pointers and/or code 
to start from.

Thanks,
Tomas

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 6108 bytes --]

Hello Tomas,

On Mon, Nov 14, 2016 at 01:23:05PM +0100, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> wrote:
> > This machine is an open hardware router by cz.nic driven by a
> > Marvell Armada 385.
> > 
> > Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> > ---
> > 
> > Hello,
> > 
> > the following components are working:
> > 
> >  - WAN port
> >  - eMMC
> 
> But I not not sure about DDR50 mode. At least with kernel 4.4, that we use
> in production, we had to limit to SDR50 to overcome I/O errors and
> communication instability, if I can remember it correctly. So it might need
> more testing with the current kernel.

I didn't test that extensively, but the eMMC serves my rootfs and I
didn't had any problems so far.

> > Still missing is support for the switch. Wireless fails to probe, didn't
> > debug this up to now. SFP is untested as is UART1.
> 
> Actually SFP is connected to SGMII interface of eth1, which is routed
> through SERDES 5. The SGMII line is shared between the SFP and metallic PHY
> 88E1514. There is a autonomous high-speed switch connected to the SFPDET
> signal from SFP cage. It disconnects the metallic SFP and connects SGMII to
> SFP once the module is connected.
> 
> The SFP is also connected to the I2C mux port 4 and to GPIO expander for
> reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
> 
> &i2c0 {
>        pinctrl-names = "default";
>        pinctrl-0 = <&i2c0_pins>;
>        status = "okay";
>        clock-frequency = <100000>;
> 
>        i2cmux@70 {
>                compatible = "nxp,pca9547";
>                #address-cells = <1>;
>                #size-cells = <0>;
>                reg = <0x70>;
>                status = "okay";
> 
> ...
> 
>                i2c@7 {
>                        /* SFP+ GPIO expander */
>                        #address-cells = <1>;
>                        #size-cells = <0>;
>                        reg = <7>;
> 
>                        sfpgpio: gpio@71 {
>                                compatible = "nxp,pca9538";
>                                reg = <0x71>;
>                                interrupt-parent = <&gpio1>;
>                                interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
>                                gpio-controller;
>                                #gpio-cells = <2>;
>                        };

I have authored a nearly identical snippet, mine looks as follows:

+               i2c@7 {
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+                       reg = <7>;
+
+                       pcawan: gpio@71 {
+                               compatible = "nxp,pca9538";
+                               reg = <0x71>;
+
+                               pinctrl-names = "default";
+                               pinctrl-0 = <&pcawan_pins>;
+
+                               interrupt-parent = <&gpio1>;
+                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+                               gpio-controller;
+                               #gpio-cells = <2>;
+
+                               interrupt-controller;
+                               #interrupt-cells = <2>;
+                       };
+               };

The interrupt-controller part doesn't seem to work though, at least

+               interrupt-parent = <&pcawan>;
+               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;

in the phy node gives an error.


>                };
> 	};
> };
> 
> We have our proprietary support hacked onto mvneta driver for disconnecting
> PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS
> altogether and let's wait till "phylink based SFP module support" or
> something alike hits upstream, so we can base the SFP support on solid code;
> unless somebody has a better idea, of course.
> 
> > 
> > 
> > diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > new file mode 100644
> > index 000000000000..d3cd8a4d713d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > @@ -0,0 +1,246 @@
> ...
> > +
> > +			/* USB part of the eSATA/USB 2.0 port */
> 
> This comment is perhaps some error inherited from my development DTS. We do
> not have any eSATA, perhaps PCIe/USB 2.0 slot.

oh right. I changed it for v3.
 
> > 
> > +			usb@58000 {
> > +				status = "okay";
> > +			};
> > +
> > +
> > +&eth0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&ge0_rgmii_pins>;
> > +	status = "okay";
> > +	phy-mode = "rgmii-id";
> > +
> > +	fixed-link {
> > +		speed = <1000>;
> > +		full-duplex;
> > +	};
> > +};
> > +
> > +&eth1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&ge1_rgmii_pins>;
> > +	status = "okay";
> > +	phy-mode = "rgmii-id";
> > +
> > +	fixed-link {
> > +		speed = <1000>;
> > +		full-duplex;
> > +	};
> > +};
> > +
> 
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch.
> The problem is that from what I have read so far the switch can not operate
> in DSA mode with two CPU ports. We currently operate the switch in "normal
> mode" with the eth0 and eth1 set to fixed-link 1000/full and with
> proprietary driver (derived from OpenWRT switch drivers). I would say that
> these records for eth0 and eth1 are therefore redundant, because it does
> nothing without the switch support and it would most likely change once we
> have DSA driver (using only eth0).

Right. They do nothing currently. In my local tree I have a
specification for the switch which allows to read the phy registers of
the lan ports, but communication isn't possible yet. For this AFAIK I
need at least one of these. I mailed a few iterations with Andrew here,
but no success so far. Also dropping one cpu port from the definition
didn't help.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

Hello Tomas,

On Mon, Nov 14, 2016 at 01:23:05PM +0100, tomas.hlavacek at nic.cz wrote:
> On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> wrote:
> > This machine is an open hardware router by cz.nic driven by a
> > Marvell Armada 385.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > ---
> > 
> > Hello,
> > 
> > the following components are working:
> > 
> >  - WAN port
> >  - eMMC
> 
> But I not not sure about DDR50 mode. At least with kernel 4.4, that we use
> in production, we had to limit to SDR50 to overcome I/O errors and
> communication instability, if I can remember it correctly. So it might need
> more testing with the current kernel.

I didn't test that extensively, but the eMMC serves my rootfs and I
didn't had any problems so far.

> > Still missing is support for the switch. Wireless fails to probe, didn't
> > debug this up to now. SFP is untested as is UART1.
> 
> Actually SFP is connected to SGMII interface of eth1, which is routed
> through SERDES 5. The SGMII line is shared between the SFP and metallic PHY
> 88E1514. There is a autonomous high-speed switch connected to the SFPDET
> signal from SFP cage. It disconnects the metallic SFP and connects SGMII to
> SFP once the module is connected.
> 
> The SFP is also connected to the I2C mux port 4 and to GPIO expander for
> reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
> 
> &i2c0 {
>        pinctrl-names = "default";
>        pinctrl-0 = <&i2c0_pins>;
>        status = "okay";
>        clock-frequency = <100000>;
> 
>        i2cmux at 70 {
>                compatible = "nxp,pca9547";
>                #address-cells = <1>;
>                #size-cells = <0>;
>                reg = <0x70>;
>                status = "okay";
> 
> ...
> 
>                i2c at 7 {
>                        /* SFP+ GPIO expander */
>                        #address-cells = <1>;
>                        #size-cells = <0>;
>                        reg = <7>;
> 
>                        sfpgpio: gpio at 71 {
>                                compatible = "nxp,pca9538";
>                                reg = <0x71>;
>                                interrupt-parent = <&gpio1>;
>                                interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
>                                gpio-controller;
>                                #gpio-cells = <2>;
>                        };

I have authored a nearly identical snippet, mine looks as follows:

+               i2c at 7 {
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+                       reg = <7>;
+
+                       pcawan: gpio at 71 {
+                               compatible = "nxp,pca9538";
+                               reg = <0x71>;
+
+                               pinctrl-names = "default";
+                               pinctrl-0 = <&pcawan_pins>;
+
+                               interrupt-parent = <&gpio1>;
+                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+                               gpio-controller;
+                               #gpio-cells = <2>;
+
+                               interrupt-controller;
+                               #interrupt-cells = <2>;
+                       };
+               };

The interrupt-controller part doesn't seem to work though, at least

+               interrupt-parent = <&pcawan>;
+               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;

in the phy node gives an error.


>                };
> 	};
> };
> 
> We have our proprietary support hacked onto mvneta driver for disconnecting
> PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS
> altogether and let's wait till "phylink based SFP module support" or
> something alike hits upstream, so we can base the SFP support on solid code;
> unless somebody has a better idea, of course.
> 
> > 
> > 
> > diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > new file mode 100644
> > index 000000000000..d3cd8a4d713d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > @@ -0,0 +1,246 @@
> ...
> > +
> > +			/* USB part of the eSATA/USB 2.0 port */
> 
> This comment is perhaps some error inherited from my development DTS. We do
> not have any eSATA, perhaps PCIe/USB 2.0 slot.

oh right. I changed it for v3.
 
> > 
> > +			usb at 58000 {
> > +				status = "okay";
> > +			};
> > +
> > +
> > +&eth0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&ge0_rgmii_pins>;
> > +	status = "okay";
> > +	phy-mode = "rgmii-id";
> > +
> > +	fixed-link {
> > +		speed = <1000>;
> > +		full-duplex;
> > +	};
> > +};
> > +
> > +&eth1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&ge1_rgmii_pins>;
> > +	status = "okay";
> > +	phy-mode = "rgmii-id";
> > +
> > +	fixed-link {
> > +		speed = <1000>;
> > +		full-duplex;
> > +	};
> > +};
> > +
> 
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch.
> The problem is that from what I have read so far the switch can not operate
> in DSA mode with two CPU ports. We currently operate the switch in "normal
> mode" with the eth0 and eth1 set to fixed-link 1000/full and with
> proprietary driver (derived from OpenWRT switch drivers). I would say that
> these records for eth0 and eth1 are therefore redundant, because it does
> nothing without the switch support and it would most likely change once we
> have DSA driver (using only eth0).

Right. They do nothing currently. In my local tree I have a
specification for the switch which allows to read the phy registers of
the lan ports, but communication isn't possible yet. For this AFAIK I
need at least one of these. I mailed a few iterations with Andrew here,
but no success so far. Also dropping one cpu port from the definition
didn't help.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a783ea53/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> 
> +               i2c@7 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <7>;
> +
> +                       pcawan: gpio@71 {
> +                               compatible = "nxp,pca9538";
> +                               reg = <0x71>;
> +
> +                               pinctrl-names = "default";
> +                               pinctrl-0 = <&pcawan_pins>;
> +
> +                               interrupt-parent = <&gpio1>;
> +                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +
> +                               gpio-controller;
> +                               #gpio-cells = <2>;
> +
> +                               interrupt-controller;
> +                               #interrupt-cells = <2>;
> +                       };
> +               };
> 
> The interrupt-controller part doesn't seem to work though, at least
> 
> +               interrupt-parent = <&pcawan>;
> +               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> 
> in the phy node gives an error.

Interrupts don't seem to work very well with the nxp,pca9538. Which
is probably why it is disabled by default.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> 
> +               i2c at 7 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <7>;
> +
> +                       pcawan: gpio at 71 {
> +                               compatible = "nxp,pca9538";
> +                               reg = <0x71>;
> +
> +                               pinctrl-names = "default";
> +                               pinctrl-0 = <&pcawan_pins>;
> +
> +                               interrupt-parent = <&gpio1>;
> +                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +
> +                               gpio-controller;
> +                               #gpio-cells = <2>;
> +
> +                               interrupt-controller;
> +                               #interrupt-cells = <2>;
> +                       };
> +               };
> 
> The interrupt-controller part doesn't seem to work though, at least
> 
> +               interrupt-parent = <&pcawan>;
> +               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> 
> in the phy node gives an error.

Interrupts don't seem to work very well with the nxp,pca9538. Which
is probably why it is disabled by default.

   Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek-x+rMaJPWets]

Hello Uwe!

On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>> 
>>  +               i2c@7 {
>>  +                       #address-cells = <1>;
>>  +                       #size-cells = <0>;
>>  +                       reg = <7>;
>>  +
>>  +                       pcawan: gpio@71 {
>>  +                               compatible = "nxp,pca9538";
>>  +                               reg = <0x71>;
>>  +
>>  +                               pinctrl-names = "default";
>>  +                               pinctrl-0 = <&pcawan_pins>;
>>  +
>>  +                               interrupt-parent = <&gpio1>;
>>  +                               interrupts = <14 
>> IRQ_TYPE_LEVEL_LOW>;
>>  +
>>  +                               gpio-controller;
>>  +                               #gpio-cells = <2>;
>>  +
>>  +                               interrupt-controller;
>>  +                               #interrupt-cells = <2>;
>>  +                       };
>>  +               };
>> 
>>  The interrupt-controller part doesn't seem to work though, at least
>> 
>>  +               interrupt-parent = <&pcawan>;
>>  +               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>> 
>>  in the phy node gives an error.
> 
> Interrupts don't seem to work very well with the nxp,pca9538. Which
> is probably why it is disabled by default.

I was thinking about this issue and I can remember that there was an 
earlier prototype that had a shared interrupt line from PHY (88E1514) 
and from the PCA9538. In this case we needed to specifically disable 
the interrupt of the PHY to release the interrupt line (which needed a 
hack into PHY driver code). The IRQ from PHY is connected as an 
ordinary input to PCA9538 in later board prototype. And the same holds 
for the production version.

Do you have CZ11NIC13 or older board revision?

Tomas



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hello Uwe!

On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> 
>>  +               i2c at 7 {
>>  +                       #address-cells = <1>;
>>  +                       #size-cells = <0>;
>>  +                       reg = <7>;
>>  +
>>  +                       pcawan: gpio at 71 {
>>  +                               compatible = "nxp,pca9538";
>>  +                               reg = <0x71>;
>>  +
>>  +                               pinctrl-names = "default";
>>  +                               pinctrl-0 = <&pcawan_pins>;
>>  +
>>  +                               interrupt-parent = <&gpio1>;
>>  +                               interrupts = <14 
>> IRQ_TYPE_LEVEL_LOW>;
>>  +
>>  +                               gpio-controller;
>>  +                               #gpio-cells = <2>;
>>  +
>>  +                               interrupt-controller;
>>  +                               #interrupt-cells = <2>;
>>  +                       };
>>  +               };
>> 
>>  The interrupt-controller part doesn't seem to work though, at least
>> 
>>  +               interrupt-parent = <&pcawan>;
>>  +               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>> 
>>  in the phy node gives an error.
> 
> Interrupts don't seem to work very well with the nxp,pca9538. Which
> is probably why it is disabled by default.

I was thinking about this issue and I can remember that there was an 
earlier prototype that had a shared interrupt line from PHY (88E1514) 
and from the PCA9538. In this case we needed to specifically disable 
the interrupt of the PHY to release the interrupt line (which needed a 
hack into PHY driver code). The IRQ from PHY is connected as an 
ordinary input to PCA9538 in later board prototype. And the same holds 
for the production version.

Do you have CZ11NIC13 or older board revision?

Tomas

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Hello Tomas,

On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> > Interrupts don't seem to work very well with the nxp,pca9538. Which
> > is probably why it is disabled by default.
> 
> I was thinking about this issue and I can remember that there was an earlier
> prototype that had a shared interrupt line from PHY (88E1514) and from the
> PCA9538. In this case we needed to specifically disable the interrupt of the
> PHY to release the interrupt line (which needed a hack into PHY driver
> code). The IRQ from PHY is connected as an ordinary input to PCA9538 in
> later board prototype. And the same holds for the production version.

That would explain why I see an "irq but nobody cared" message when
booting the original system.

This isn't the problem I meant though. When adding interrupt-parent =
<&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get an
error saying that there is no irq domain associated with this device.
 
> Do you have CZ11NIC13 or older board revision?

CZ11NIC12 is indicated on my board.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

Hello Tomas,

On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Interrupts don't seem to work very well with the nxp,pca9538. Which
> > is probably why it is disabled by default.
> 
> I was thinking about this issue and I can remember that there was an earlier
> prototype that had a shared interrupt line from PHY (88E1514) and from the
> PCA9538. In this case we needed to specifically disable the interrupt of the
> PHY to release the interrupt line (which needed a hack into PHY driver
> code). The IRQ from PHY is connected as an ordinary input to PCA9538 in
> later board prototype. And the same holds for the production version.

That would explain why I see an "irq but nobody cared" message when
booting the original system.

This isn't the problem I meant though. When adding interrupt-parent =
<&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get an
error saying that there is no irq domain associated with this device.
 
> Do you have CZ11NIC13 or older board revision?

CZ11NIC12 is indicated on my board.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161120/6ded9bfe/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek]

Hi Uwe!

On Sun, Nov 20, 2016 at 9:30 PM, Uwe Kleine-König 
<uwe@kleine-koenig.org> wrote:
> Hello Tomas,
> 
> On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek@nic.cz wrote:
>>  On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  > Interrupts don't seem to work very well with the nxp,pca9538. 
>> Which
>>  > is probably why it is disabled by default.
>> 
>>  I was thinking about this issue and I can remember that there was 
>> an earlier
>>  prototype that had a shared interrupt line from PHY (88E1514) and 
>> from the
>>  PCA9538. In this case we needed to specifically disable the 
>> interrupt of the
>>  PHY to release the interrupt line (which needed a hack into PHY 
>> driver
>>  code). The IRQ from PHY is connected as an ordinary input to 
>> PCA9538 in
>>  later board prototype. And the same holds for the production 
>> version.
> 
> That would explain why I see an "irq but nobody cared" message when
> booting the original system.
> 
> This isn't the problem I meant though. When adding interrupt-parent =
> <&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get 
> an
> error saying that there is no irq domain associated with this device.
> 
>>  Do you have CZ11NIC13 or older board revision?
> 
> CZ11NIC12 is indicated on my board.

:-( Well, this board version has wrongly matched length of some 
differential pairs, IRQ from 88E1514 is connected differently, there 
are slight differences in power supplies and (if I am not mistaken) 
something changed in RTC support circuitry. It looks like a huge 
mistake on our side.

Anyway I took your patch and tried few things:
- clean up comments
- add pca9538 interrupt-controller
- remove rtc disable (WFM with CZ11NIC13, which is the production board)
- add MBUS mem regions for CESA
- add IRQ for 88E1514 PHY - and there is a problem:

It seems that libphy is probed before pca9538 and we end up with:
[    4.217550] libphy: orion_mdio_bus: probed
[    4.221777] irq: no irq domain found for 
/soc/internal-regs/i2c@11000/i2cmux@70/i2c@7/gpio@71 !

Any clue where to look in order to defer probing libphy or at least 
orion_mdio_bus?

I'll post my version of the patch without the PHY IRQ (therefore 
polling will kick in).

Thanks,
Tomas

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hi Uwe!

On Sun, Nov 20, 2016 at 9:30 PM, Uwe Kleine-K?nig 
<uwe@kleine-koenig.org> wrote:
> Hello Tomas,
> 
> On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
>>  On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  > Interrupts don't seem to work very well with the nxp,pca9538. 
>> Which
>>  > is probably why it is disabled by default.
>> 
>>  I was thinking about this issue and I can remember that there was 
>> an earlier
>>  prototype that had a shared interrupt line from PHY (88E1514) and 
>> from the
>>  PCA9538. In this case we needed to specifically disable the 
>> interrupt of the
>>  PHY to release the interrupt line (which needed a hack into PHY 
>> driver
>>  code). The IRQ from PHY is connected as an ordinary input to 
>> PCA9538 in
>>  later board prototype. And the same holds for the production 
>> version.
> 
> That would explain why I see an "irq but nobody cared" message when
> booting the original system.
> 
> This isn't the problem I meant though. When adding interrupt-parent =
> <&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get 
> an
> error saying that there is no irq domain associated with this device.
> 
>>  Do you have CZ11NIC13 or older board revision?
> 
> CZ11NIC12 is indicated on my board.

:-( Well, this board version has wrongly matched length of some 
differential pairs, IRQ from 88E1514 is connected differently, there 
are slight differences in power supplies and (if I am not mistaken) 
something changed in RTC support circuitry. It looks like a huge 
mistake on our side.

Anyway I took your patch and tried few things:
- clean up comments
- add pca9538 interrupt-controller
- remove rtc disable (WFM with CZ11NIC13, which is the production board)
- add MBUS mem regions for CESA
- add IRQ for 88E1514 PHY - and there is a problem:

It seems that libphy is probed before pca9538 and we end up with:
[    4.217550] libphy: orion_mdio_bus: probed
[    4.221777] irq: no irq domain found for 
/soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !

Any clue where to look in order to defer probing libphy or at least 
orion_mdio_bus?

I'll post my version of the patch without the PHY IRQ (therefore 
polling will kick in).

Thanks,
Tomas

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Turris Omnia board by CZ.NIC:

  * Marvell Armada 385 SoC
  * 1 or 2 GB DDR3
  * eMMC
  * 8 MB SPI flash (U-Boot and rescue Linux image)
  * 88E1514 PHY
  * 88E6176 Ethernet switch (not supported)

Supported board revision: CZ11NIC13 (production board).

Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
---
Changes since Uwe's version:

- add MBUS regions (needed for Marvell CESA)
- remove rtc disable (WFM with CZ11NIC13 = production board)
- cleanup comments

Unsupported peripherals:
- MV88E7176 switch
- SFP
- LEDs

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
 2 files changed, 280 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f1d3b9ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 0000000..5ef3d62
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+	model = "Turris Omnia";
+	compatible = "cznic,turris-omnia", "marvell,armada385", \
+			"marvell,armada380";
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+		internal-regs {
+
+			/* USB part of the PCIe2/USB 2.0 port */
+			usb@58000 {
+				status = "okay";
+			};
+
+			sata@a8000 {
+				status = "okay";
+			};
+
+			sdhci@d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3@f0000 {
+				status = "okay";
+			};
+
+			usb3@f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie@1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@3,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
+
+/* Connected to 88E6176 switch, port 6 */
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* Connected to 88E6176 switch, port 5 */
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux@70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";
+
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			status = "okay";
+
+			/* STM32F0 command interface at address 0x2a.
+			 * STM32F0 LED interface at address 0x2b.
+			 */
+
+			eeprom@54 {
+				compatible = "at,24c64";
+				reg = <0x54>;
+
+				/* The EEPROM contains data for bootloader.
+				 * Contents:
+				 *	struct omnia_eeprom {
+				 *		u32 magic; (=0x0341a034)
+				 *		u32 ramsize;
+				 *		char region[4] (=0x0);
+				 *		u32 crc32;
+				 *	};
+				 */
+			};
+		};
+
+		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
+		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
+		 * Channel 3: Routed to PCIe2 connector (CN62A).
+		 * Channel 4: Routed to SFP+.
+		 * Channel 5: ATSHA204A at address 0x64.
+		 * Channel 6: Routed to user pin header CN11.
+		 */
+
+		i2c@7 {
+			/* GPIO expander for SFP+ signals */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+
+			wangpio: gpio@71 {
+				compatible = "nxp,pca9538";
+				reg = <0x71>;
+				interrupt-parent = <&gpio1>;
+				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};
+
+&mdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy@1 {
+		status = "okay";
+		compatible = "ethernet-phy-id0141.0DD1", \
+				"ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		/* IRQ is connected to PCA9538 pin 7. Currently it
+		 * can not be utilized.
+		 */
+	};
+
+	/* Switch MV88E7176 at address 0x10. */
+};
+
+&pinctrl {
+	spi0cs1_pins: spi0-pins-0cs1 {
+		marvell,pins = "mpp26";
+		marvell,function = "spi0";
+	};
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+	status = "okay";
+
+	spi-nor@0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition@0 {
+			reg = <0x0 0x00100000>;
+			label = "U-Boot";
+		};
+
+		partition@1 {
+			reg = <0x00100000 0x00700000>;
+			label = "Rescue system";
+		};
+	};
+
+	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */
+};
+
+&uart0 {
+	/* Pin header CN10. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	/* Pin header CN11. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+	status = "okay";
+};
+
-- 
2.7.4

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Turris Omnia board by CZ.NIC:

  * Marvell Armada 385 SoC
  * 1 or 2 GB DDR3
  * eMMC
  * 8 MB SPI flash (U-Boot and rescue Linux image)
  * 88E1514 PHY
  * 88E6176 Ethernet switch (not supported)

Supported board revision: CZ11NIC13 (production board).

Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
---
Changes since Uwe's version:

- add MBUS regions (needed for Marvell CESA)
- remove rtc disable (WFM with CZ11NIC13 = production board)
- cleanup comments

Unsupported peripherals:
- MV88E7176 switch
- SFP
- LEDs

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
 2 files changed, 280 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f1d3b9ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 0000000..5ef3d62
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+	model = "Turris Omnia";
+	compatible = "cznic,turris-omnia", "marvell,armada385", \
+			"marvell,armada380";
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+		internal-regs {
+
+			/* USB part of the PCIe2/USB 2.0 port */
+			usb at 58000 {
+				status = "okay";
+			};
+
+			sata at a8000 {
+				status = "okay";
+			};
+
+			sdhci at d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3 at f0000 {
+				status = "okay";
+			};
+
+			usb3 at f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			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";
+			};
+		};
+	};
+};
+
+/* Connected to 88E6176 switch, port 6 */
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* Connected to 88E6176 switch, port 5 */
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux at 70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";
+
+		i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			status = "okay";
+
+			/* STM32F0 command interface at address 0x2a.
+			 * STM32F0 LED interface at address 0x2b.
+			 */
+
+			eeprom at 54 {
+				compatible = "at,24c64";
+				reg = <0x54>;
+
+				/* The EEPROM contains data for bootloader.
+				 * Contents:
+				 *	struct omnia_eeprom {
+				 *		u32 magic; (=0x0341a034)
+				 *		u32 ramsize;
+				 *		char region[4] (=0x0);
+				 *		u32 crc32;
+				 *	};
+				 */
+			};
+		};
+
+		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
+		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
+		 * Channel 3: Routed to PCIe2 connector (CN62A).
+		 * Channel 4: Routed to SFP+.
+		 * Channel 5: ATSHA204A at address 0x64.
+		 * Channel 6: Routed to user pin header CN11.
+		 */
+
+		i2c at 7 {
+			/* GPIO expander for SFP+ signals */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+
+			wangpio: gpio at 71 {
+				compatible = "nxp,pca9538";
+				reg = <0x71>;
+				interrupt-parent = <&gpio1>;
+				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};
+
+&mdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy at 1 {
+		status = "okay";
+		compatible = "ethernet-phy-id0141.0DD1", \
+				"ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		/* IRQ is connected to PCA9538 pin 7. Currently it
+		 * can not be utilized.
+		 */
+	};
+
+	/* Switch MV88E7176 at address 0x10. */
+};
+
+&pinctrl {
+	spi0cs1_pins: spi0-pins-0cs1 {
+		marvell,pins = "mpp26";
+		marvell,function = "spi0";
+	};
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+	status = "okay";
+
+	spi-nor at 0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition at 0 {
+			reg = <0x0 0x00100000>;
+			label = "U-Boot";
+		};
+
+		partition at 1 {
+			reg = <0x00100000 0x00700000>;
+			label = "Rescue system";
+		};
+	};
+
+	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */
+};
+
+&uart0 {
+	/* Pin header CN10. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	/* Pin header CN11. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+	status = "okay";
+};
+
-- 
2.7.4

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Turris Omnia board by CZ.NIC:

  * Marvell Armada 385 SoC
  * 1 or 2 GB DDR3
  * eMMC
  * 8 MB SPI flash (U-Boot and rescue Linux image)
  * 88E1514 PHY
  * 88E6176 Ethernet switch (not supported)

Supported board revision: CZ11NIC13 (production board).

Signed-off-by: Tomas Hlavacek <tmshlvck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes since Uwe's version:

- add MBUS regions (needed for Marvell CESA)
- remove rtc disable (WFM with CZ11NIC13 = production board)
- cleanup comments

Unsupported peripherals:
- MV88E7176 switch
- SFP
- LEDs

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
 2 files changed, 280 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f1d3b9ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 0000000..5ef3d62
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+	model = "Turris Omnia";
+	compatible = "cznic,turris-omnia", "marvell,armada385", \
+			"marvell,armada380";
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+		internal-regs {
+
+			/* USB part of the PCIe2/USB 2.0 port */
+			usb@58000 {
+				status = "okay";
+			};
+
+			sata@a8000 {
+				status = "okay";
+			};
+
+			sdhci@d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3@f0000 {
+				status = "okay";
+			};
+
+			usb3@f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie@1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+
+			pcie@3,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
+
+/* Connected to 88E6176 switch, port 6 */
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* Connected to 88E6176 switch, port 5 */
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux@70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";
+
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			status = "okay";
+
+			/* STM32F0 command interface at address 0x2a.
+			 * STM32F0 LED interface at address 0x2b.
+			 */
+
+			eeprom@54 {
+				compatible = "at,24c64";
+				reg = <0x54>;
+
+				/* The EEPROM contains data for bootloader.
+				 * Contents:
+				 *	struct omnia_eeprom {
+				 *		u32 magic; (=0x0341a034)
+				 *		u32 ramsize;
+				 *		char region[4] (=0x0);
+				 *		u32 crc32;
+				 *	};
+				 */
+			};
+		};
+
+		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
+		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
+		 * Channel 3: Routed to PCIe2 connector (CN62A).
+		 * Channel 4: Routed to SFP+.
+		 * Channel 5: ATSHA204A at address 0x64.
+		 * Channel 6: Routed to user pin header CN11.
+		 */
+
+		i2c@7 {
+			/* GPIO expander for SFP+ signals */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+
+			wangpio: gpio@71 {
+				compatible = "nxp,pca9538";
+				reg = <0x71>;
+				interrupt-parent = <&gpio1>;
+				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};
+
+&mdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy@1 {
+		status = "okay";
+		compatible = "ethernet-phy-id0141.0DD1", \
+				"ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		/* IRQ is connected to PCA9538 pin 7. Currently it
+		 * can not be utilized.
+		 */
+	};
+
+	/* Switch MV88E7176 at address 0x10. */
+};
+
+&pinctrl {
+	spi0cs1_pins: spi0-pins-0cs1 {
+		marvell,pins = "mpp26";
+		marvell,function = "spi0";
+	};
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+	status = "okay";
+
+	spi-nor@0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition@0 {
+			reg = <0x0 0x00100000>;
+			label = "U-Boot";
+		};
+
+		partition@1 {
+			reg = <0x00100000 0x00700000>;
+			label = "Rescue system";
+		};
+	};
+
+	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */
+};
+
+&uart0 {
+	/* Pin header CN10. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	/* Pin header CN11. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+	status = "okay";
+};
+
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Andrew Lunn]

> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf

Hi Tomas

Cool that there is a link to the schematics. But please could you put
it lower down. It is more likely to be seen if it comes after the
copyright and license section.

> +			sdhci@d8000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&sdhci_pins>;
> +				status = "okay";
> +
> +				bus-width = <8>;
> +				no-1-8-v;
> +				non-removable;
> +			};

> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	i2cmux@70 {
> +		compatible = "nxp,pca9547";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		status = "okay";
> +
> +		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> +		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> +		 * Channel 3: Routed to PCIe2 connector (CN62A).
> +		 * Channel 4: Routed to SFP+.
> +		 * Channel 5: ATSHA204A at address 0x64.
> +		 * Channel 6: Routed to user pin header CN11.
> +		 */

I've not looked at how the pca9547 works.... Will it instantiate a bus
only if there is a node in the device tree with a reg property?

What i'm thinking is that it is possible to indicate to the i2c core
that a device is on a bus using echo to a file. But this only works if
the bus exists. You could for example say using echo that there is an
at24 EEPROM on channel 4 and get access to the EEPROM inside the SFP
module. But that only works if the i2c bus exists. Does it?

No leds? No buttons via gpio-keys?

   Andrew

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Andrew Lunn]

> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf

Hi Tomas

Cool that there is a link to the schematics. But please could you put
it lower down. It is more likely to be seen if it comes after the
copyright and license section.

> +			sdhci at d8000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&sdhci_pins>;
> +				status = "okay";
> +
> +				bus-width = <8>;
> +				no-1-8-v;
> +				non-removable;
> +			};

> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	i2cmux at 70 {
> +		compatible = "nxp,pca9547";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		status = "okay";
> +
> +		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> +		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> +		 * Channel 3: Routed to PCIe2 connector (CN62A).
> +		 * Channel 4: Routed to SFP+.
> +		 * Channel 5: ATSHA204A at address 0x64.
> +		 * Channel 6: Routed to user pin header CN11.
> +		 */

I've not looked at how the pca9547 works.... Will it instantiate a bus
only if there is a node in the device tree with a reg property?

What i'm thinking is that it is possible to indicate to the i2c core
that a device is on a bus using echo to a file. But this only works if
the bus exists. You could for example say using echo that there is an
at24 EEPROM on channel 4 and get access to the EEPROM inside the SFP
module. But that only works if the i2c bus exists. Does it?

No leds? No buttons via gpio-keys?

   Andrew

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]

On 11/23/2016 01:35 AM, Andrew Lunn wrote:
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -0,0 +1,279 @@
>> +/*
>> + * Device Tree file for the Turris Omnia
>> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
>
> Cool that there is a link to the schematics. But please could you put
> it lower down. It is more likely to be seen if it comes after the
> copyright and license section.

I added to the top because that's where I would look. But checking other
dts files it seems indeed to be more common after the copyright stuff.
I'd suggest to even start a new comment (i.e.

	 * last blabla of copyright
	 */

	/*
	 * Schematic available at ...

) to be more "loud".

@Tomas: I think it doesn't make sense when we alternate sending patches
without prior arrangement. Do you already work on a v5? If not I can do
that to fix the last few comments. Not sure when a submission is too
late to enter v4.10, but I think the window isn't that big any more.

> No leds? No buttons via gpio-keys?

The leds are controlled by a Cortex-M0 and without intervention blink
according to a hardware function (network, power, pci). IMHO that's ok
for an initial setup.

And there are no buttons that are routed to the Armada CPU. Just a reset
button (well, ok, this one is routed to the Armada CPU, but you cannot
make this a gpio-key :-) and the other button is used to control the
brightness of the LEDs and is only routed to the M0.

Best regards
Uwe


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

On 11/23/2016 01:35 AM, Andrew Lunn wrote:
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -0,0 +1,279 @@
>> +/*
>> + * Device Tree file for the Turris Omnia
>> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
>
> Cool that there is a link to the schematics. But please could you put
> it lower down. It is more likely to be seen if it comes after the
> copyright and license section.

I added to the top because that's where I would look. But checking other
dts files it seems indeed to be more common after the copyright stuff.
I'd suggest to even start a new comment (i.e.

	 * last blabla of copyright
	 */

	/*
	 * Schematic available at ...

) to be more "loud".

@Tomas: I think it doesn't make sense when we alternate sending patches
without prior arrangement. Do you already work on a v5? If not I can do
that to fix the last few comments. Not sure when a submission is too
late to enter v4.10, but I think the window isn't that big any more.

> No leds? No buttons via gpio-keys?

The leds are controlled by a Cortex-M0 and without intervention blink
according to a hardware function (network, power, pci). IMHO that's ok
for an initial setup.

And there are no buttons that are routed to the Armada CPU. Just a reset
button (well, ok, this one is routed to the Armada CPU, but you cannot
make this a gpio-key :-) and the other button is used to control the
brightness of the LEDs and is only routed to the M0.

Best regards
Uwe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/8bd849c4/attachment-0001.sig>

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Andrew Lunn]

> @Tomas: I think it doesn't make sense when we alternate sending patches
> without prior arrangement. Do you already work on a v5? If not I can do
> that to fix the last few comments. Not sure when a submission is too
> late to enter v4.10, but I think the window isn't that big any more.

It is getting a bit late. But maybe Linus will add in another -rc
week.

> 
> > No leds? No buttons via gpio-keys?
> 
> The leds are controlled by a Cortex-M0 and without intervention blink
> according to a hardware function (network, power, pci). IMHO that's ok
> for an initial setup.

Yes. That is fine. It is just unusual. Most boards have gpio-led and
gpio-keys, which are easy to add. That is why i asked. Adding an LED
driver which talks to this M0 can be added later.

       Andrew

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Andrew Lunn]

> @Tomas: I think it doesn't make sense when we alternate sending patches
> without prior arrangement. Do you already work on a v5? If not I can do
> that to fix the last few comments. Not sure when a submission is too
> late to enter v4.10, but I think the window isn't that big any more.

It is getting a bit late. But maybe Linus will add in another -rc
week.

> 
> > No leds? No buttons via gpio-keys?
> 
> The leds are controlled by a Cortex-M0 and without intervention blink
> according to a hardware function (network, power, pci). IMHO that's ok
> for an initial setup.

Yes. That is fine. It is just unusual. Most boards have gpio-led and
gpio-keys, which are easy to add. That is why i asked. Adding an LED
driver which talks to this M0 can be added later.

       Andrew

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> Yes. That is fine. It is just unusual. Most boards have gpio-led and
> gpio-keys, which are easy to add. That is why i asked. Adding an LED
> driver which talks to this M0 can be added later.

Actually the WiP driver for MCU LED interface, that we use in our 
kernel is here: 
https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb

It definitely needs some cleanup and it adds non-standard features 
(main PWM for all LEDs, autonomous blink mode, colors) via custom /sys 
files, which I suspect that is not going to be acceptable for upstream. 
Let's keep it for the next iteration.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> Yes. That is fine. It is just unusual. Most boards have gpio-led and
> gpio-keys, which are easy to add. That is why i asked. Adding an LED
> driver which talks to this M0 can be added later.

Actually the WiP driver for MCU LED interface, that we use in our 
kernel is here: 
https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb

It definitely needs some cleanup and it adds non-standard features 
(main PWM for all LEDs, autonomous blink mode, colors) via custom /sys 
files, which I suspect that is not going to be acceptable for upstream. 
Let's keep it for the next iteration.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Tomas Hlavacek]

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> Yes. That is fine. It is just unusual. Most boards have gpio-led and
> gpio-keys, which are easy to add. That is why i asked. Adding an LED
> driver which talks to this M0 can be added later.

Actually the WiP driver for MCU LED interface, that we use in our 
kernel is here: 
https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb

It definitely needs some cleanup and it adds non-standard features 
(main PWM for all LEDs, autonomous blink mode, colors) via custom /sys 
files, which I suspect that is not going to be acceptable for upstream. 
Let's keep it for the next iteration.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

Hello,

[trimmed Cc: a bit to annoy less]

On 11/25/2016 01:49 PM, Tomas Hlavacek wrote:
> On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>>  @Tomas: I think it doesn't make sense when we alternate sending patches
>>>  without prior arrangement. Do you already work on a v5? If not I can do
>>>  that to fix the last few comments. Not sure when a submission is too
>>>  late to enter v4.10, but I think the window isn't that big any more.
>>
>> It is getting a bit late. But maybe Linus will add in another -rc
>> week.

To keep the dice rolling I sent a v5 with is somewhere in the middle
between my v3 and Tomas RFC patch. Assuming Tomas is happy with this
change, can we still get it into 4.10? This would help me to put this in
the Debian kernel for the next release.

>>>  > No leds? No buttons via gpio-keys?
>>>
>>>  The leds are controlled by a Cortex-M0 and without intervention blink
>>>  according to a hardware function (network, power, pci). IMHO that's ok
>>>  for an initial setup.
>>
>> Yes. That is fine. It is just unusual. Most boards have gpio-led and
>> gpio-keys, which are easy to add. That is why i asked. Adding an LED
>> driver which talks to this M0 can be added later.
> 
> Actually the WiP driver for MCU LED interface, that we use in our kernel
> is here:
> https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
> 
> 
> It definitely needs some cleanup and it adds non-standard features (main
> PWM for all LEDs, autonomous blink mode, colors) via custom /sys files,
> which I suspect that is not going to be acceptable for upstream. Let's
> keep it for the next iteration.

Ack, the leds are one of the less critical things for the machine. I'd
like to tackle the switch next.

Best regards
Uwe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/05e21cc2/attachment.sig>

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Pavel Machek]

Hi!

> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
> 
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
> 
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.

Actually, LEDs that can do PWM intensity on their own are common and
supported.

LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.

In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Pavel Machek]

Hi!

> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
> 
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
> 
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.

Actually, LEDs that can do PWM intensity on their own are common and
supported.

LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.

In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Pavel Machek]

Hi!

> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
> 
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
> 
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.

Actually, LEDs that can do PWM intensity on their own are common and
supported.

LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.

In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 9984 bytes --]

Hello Tomas,

calling it v4 would be nice.

On Wed, Nov 23, 2016 at 01:09:20AM +0100, Tomas Hlavacek wrote:
> Turris Omnia board by CZ.NIC:
> 
>   * Marvell Armada 385 SoC
>   * 1 or 2 GB DDR3
>   * eMMC
>   * 8 MB SPI flash (U-Boot and rescue Linux image)
>   * 88E1514 PHY
>   * 88E6176 Ethernet switch (not supported)
> 
> Supported board revision: CZ11NIC13 (production board).
> 
> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>

As you picked my v3, you should keep my S-o-b.

> ---
> Changes since Uwe's version:
> 
> - add MBUS regions (needed for Marvell CESA)
> - remove rtc disable (WFM with CZ11NIC13 = production board)

If I do

	mw 0xf10184a0 0xfd4d4cfa

in the boot loader, it seems to work for me, too. You don't need that?

> - cleanup comments
> 
> Unsupported peripherals:
> - MV88E7176 switch
> - SFP
> - LEDs

LEDs is not that bad IMHO, because they work. You just cannot change
their function, but they blink according to their default trigger.
 
> ---
>  arch/arm/boot/dts/Makefile                    |   1 +
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
>  2 files changed, 280 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f1d3b9ff 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>  	armada-385-db-ap.dtb \
>  	armada-385-linksys-caiman.dtb \
>  	armada-385-linksys-cobra.dtb \
> +	armada-385-turris-omnia.dtb \
>  	armada-388-clearfog.dtb \
>  	armada-388-db.dtb \
>  	armada-388-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 0000000..5ef3d62
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
> + *
> + * Copyright (C) 2016 Uwe Kleine-König <uwe@kleine-koenig.org>
> + * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "armada-385.dtsi"
> +
> +/ {
> +	model = "Turris Omnia";
> +	compatible = "cznic,turris-omnia", "marvell,armada385", \
> +			"marvell,armada380";

You don't need a \ here AFAIK.

> +
> +	chosen {
> +		stdout-path = &uart0;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x40000000>; /* 1024 MB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> +			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> +
> +		internal-regs {
> +
> +			/* USB part of the PCIe2/USB 2.0 port */
> +			usb@58000 {
> +				status = "okay";
> +			};
> +
> +			sata@a8000 {
> +				status = "okay";
> +			};
> +
> +			sdhci@d8000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&sdhci_pins>;
> +				status = "okay";
> +
> +				bus-width = <8>;
> +				no-1-8-v;
> +				non-removable;
> +			};
> +
> +			usb3@f0000 {
> +				status = "okay";
> +			};
> +
> +			usb3@f8000 {
> +				status = "okay";
> +			};
> +		};
> +
> +		pcie-controller {
> +			status = "okay";
> +
> +			pcie@1,0 {
> +				/* Port 0, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie@2,0 {
> +				/* Port 1, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie@3,0 {
> +				/* Port 2, Lane 0 */
> +				status = "okay";
> +			};
> +		};
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 6 */
> +&eth0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge0_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 5 */
> +&eth1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge1_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* WAN port */
> +&eth2 {
> +	status = "okay";
> +	phy-mode = "sgmii";
> +	phy = <&phy1>;
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	i2cmux@70 {
> +		compatible = "nxp,pca9547";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		status = "okay";
> +
> +		i2c@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +			status = "okay";
> +
> +			/* STM32F0 command interface at address 0x2a.
> +			 * STM32F0 LED interface at address 0x2b.
> +			 */

Should this better be:

			/*
			 * STM32F0 command interface at address 0x2a.
			 * STM32F0 LED interface at address 0x2b.
			 */

As is recommended for comments in .c?

> +
> +			eeprom@54 {
> +				compatible = "at,24c64";
> +				reg = <0x54>;
> +
> +				/* The EEPROM contains data for bootloader.
> +				 * Contents:
> +				 *	struct omnia_eeprom {
> +				 *		u32 magic; (=0x0341a034)
> +				 *		u32 ramsize;
ramsize in GiB?

> +				 *		char region[4] (=0x0);
This is for the WLAN regdomain, right?

> +				 *		u32 crc32;
> +				 *	};
> +				 */
ditto for the comment format.

> +			};
> +		};
> +
> +		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> +		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> +		 * Channel 3: Routed to PCIe2 connector (CN62A).
> +		 * Channel 4: Routed to SFP+.
> +		 * Channel 5: ATSHA204A at address 0x64.
> +		 * Channel 6: Routed to user pin header CN11.
> +		 */
I'd like to keep the busses as Andrew already pointed out. For example
this might make it possible to use i2c-tools to read out the mac address
from the ATSHA.

> +		i2c@7 {
> +			/* GPIO expander for SFP+ signals */
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <7>;
> +
> +			wangpio: gpio@71 {
> +				compatible = "nxp,pca9538";
> +				reg = <0x71>;
> +				interrupt-parent = <&gpio1>;
> +				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +			};
> +		};
> +	};
> +};
> +
> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +	status = "okay";
> +
> +	phy1: phy@1 {
> +		status = "okay";
> +		compatible = "ethernet-phy-id0141.0DD1", \
> +				"ethernet-phy-ieee802.3-c22";

Drop the \

> +		reg = <1>;
> +		/* IRQ is connected to PCA9538 pin 7. Currently it
> +		 * can not be utilized.
> +		 */
> +	};
> +
> +	/* Switch MV88E7176 at address 0x10. */
> +};
> +
> +&pinctrl {
> +	spi0cs1_pins: spi0-pins-0cs1 {
> +		marvell,pins = "mpp26";
> +		marvell,function = "spi0";
> +	};

Why did you drop the pcawan pinctrl?

> +};
> +
> +&spi0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;

Oh, this is wrong (already in my patch): this is cs0 not cs1.

> +	status = "okay";
> +
> +	spi-nor@0 {
> +		compatible = "spansion,s25fl164k", "jedec,spi-nor";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0>;
> +		spi-max-frequency = <40000000>;
> +
> +		partition@0 {
> +			reg = <0x0 0x00100000>;
> +			label = "U-Boot";
> +		};
> +
> +		partition@1 {
> +			reg = <0x00100000 0x00700000>;
> +			label = "Rescue system";
> +		};
> +	};
> +
> +	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */

Looks strange. What about

	/* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */

Maybe also add the node for this pin to &pinctrl, but don't use it in
&spi0.pinctrl-0? This would nicely document the MPP26 part.

> +};
> +
> +&uart0 {
> +	/* Pin header CN10. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	/* Pin header CN11. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>;
> +	status = "okay";
> +};
> +

Trailing new line

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

Hello Tomas,

calling it v4 would be nice.

On Wed, Nov 23, 2016 at 01:09:20AM +0100, Tomas Hlavacek wrote:
> Turris Omnia board by CZ.NIC:
> 
>   * Marvell Armada 385 SoC
>   * 1 or 2 GB DDR3
>   * eMMC
>   * 8 MB SPI flash (U-Boot and rescue Linux image)
>   * 88E1514 PHY
>   * 88E6176 Ethernet switch (not supported)
> 
> Supported board revision: CZ11NIC13 (production board).
> 
> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>

As you picked my v3, you should keep my S-o-b.

> ---
> Changes since Uwe's version:
> 
> - add MBUS regions (needed for Marvell CESA)
> - remove rtc disable (WFM with CZ11NIC13 = production board)

If I do

	mw 0xf10184a0 0xfd4d4cfa

in the boot loader, it seems to work for me, too. You don't need that?

> - cleanup comments
> 
> Unsupported peripherals:
> - MV88E7176 switch
> - SFP
> - LEDs

LEDs is not that bad IMHO, because they work. You just cannot change
their function, but they blink according to their default trigger.
 
> ---
>  arch/arm/boot/dts/Makefile                    |   1 +
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
>  2 files changed, 280 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f1d3b9ff 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>  	armada-385-db-ap.dtb \
>  	armada-385-linksys-caiman.dtb \
>  	armada-385-linksys-cobra.dtb \
> +	armada-385-turris-omnia.dtb \
>  	armada-388-clearfog.dtb \
>  	armada-388-db.dtb \
>  	armada-388-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 0000000..5ef3d62
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
> + *
> + * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> + * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "armada-385.dtsi"
> +
> +/ {
> +	model = "Turris Omnia";
> +	compatible = "cznic,turris-omnia", "marvell,armada385", \
> +			"marvell,armada380";

You don't need a \ here AFAIK.

> +
> +	chosen {
> +		stdout-path = &uart0;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x40000000>; /* 1024 MB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> +			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> +
> +		internal-regs {
> +
> +			/* USB part of the PCIe2/USB 2.0 port */
> +			usb at 58000 {
> +				status = "okay";
> +			};
> +
> +			sata at a8000 {
> +				status = "okay";
> +			};
> +
> +			sdhci at d8000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&sdhci_pins>;
> +				status = "okay";
> +
> +				bus-width = <8>;
> +				no-1-8-v;
> +				non-removable;
> +			};
> +
> +			usb3 at f0000 {
> +				status = "okay";
> +			};
> +
> +			usb3 at f8000 {
> +				status = "okay";
> +			};
> +		};
> +
> +		pcie-controller {
> +			status = "okay";
> +
> +			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";
> +			};
> +		};
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 6 */
> +&eth0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge0_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 5 */
> +&eth1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge1_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* WAN port */
> +&eth2 {
> +	status = "okay";
> +	phy-mode = "sgmii";
> +	phy = <&phy1>;
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	i2cmux at 70 {
> +		compatible = "nxp,pca9547";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		status = "okay";
> +
> +		i2c at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +			status = "okay";
> +
> +			/* STM32F0 command interface at address 0x2a.
> +			 * STM32F0 LED interface at address 0x2b.
> +			 */

Should this better be:

			/*
			 * STM32F0 command interface at address 0x2a.
			 * STM32F0 LED interface at address 0x2b.
			 */

As is recommended for comments in .c?

> +
> +			eeprom at 54 {
> +				compatible = "at,24c64";
> +				reg = <0x54>;
> +
> +				/* The EEPROM contains data for bootloader.
> +				 * Contents:
> +				 *	struct omnia_eeprom {
> +				 *		u32 magic; (=0x0341a034)
> +				 *		u32 ramsize;
ramsize in GiB?

> +				 *		char region[4] (=0x0);
This is for the WLAN regdomain, right?

> +				 *		u32 crc32;
> +				 *	};
> +				 */
ditto for the comment format.

> +			};
> +		};
> +
> +		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> +		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> +		 * Channel 3: Routed to PCIe2 connector (CN62A).
> +		 * Channel 4: Routed to SFP+.
> +		 * Channel 5: ATSHA204A at address 0x64.
> +		 * Channel 6: Routed to user pin header CN11.
> +		 */
I'd like to keep the busses as Andrew already pointed out. For example
this might make it possible to use i2c-tools to read out the mac address
from the ATSHA.

> +		i2c at 7 {
> +			/* GPIO expander for SFP+ signals */
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <7>;
> +
> +			wangpio: gpio at 71 {
> +				compatible = "nxp,pca9538";
> +				reg = <0x71>;
> +				interrupt-parent = <&gpio1>;
> +				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +			};
> +		};
> +	};
> +};
> +
> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +	status = "okay";
> +
> +	phy1: phy at 1 {
> +		status = "okay";
> +		compatible = "ethernet-phy-id0141.0DD1", \
> +				"ethernet-phy-ieee802.3-c22";

Drop the \

> +		reg = <1>;
> +		/* IRQ is connected to PCA9538 pin 7. Currently it
> +		 * can not be utilized.
> +		 */
> +	};
> +
> +	/* Switch MV88E7176 at address 0x10. */
> +};
> +
> +&pinctrl {
> +	spi0cs1_pins: spi0-pins-0cs1 {
> +		marvell,pins = "mpp26";
> +		marvell,function = "spi0";
> +	};

Why did you drop the pcawan pinctrl?

> +};
> +
> +&spi0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;

Oh, this is wrong (already in my patch): this is cs0 not cs1.

> +	status = "okay";
> +
> +	spi-nor at 0 {
> +		compatible = "spansion,s25fl164k", "jedec,spi-nor";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0>;
> +		spi-max-frequency = <40000000>;
> +
> +		partition at 0 {
> +			reg = <0x0 0x00100000>;
> +			label = "U-Boot";
> +		};
> +
> +		partition at 1 {
> +			reg = <0x00100000 0x00700000>;
> +			label = "Rescue system";
> +		};
> +	};
> +
> +	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */

Looks strange. What about

	/* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */

Maybe also add the node for this pin to &pinctrl, but don't use it in
&spi0.pinctrl-0? This would nicely document the MPP26 part.

> +};
> +
> +&uart0 {
> +	/* Pin header CN10. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	/* Pin header CN11. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>;
> +	status = "okay";
> +};
> +

Trailing new line

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161123/dac38887/attachment-0001.sig>

Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 10076 bytes --]

Hello Tomas,

calling it v4 would be nice.

On Wed, Nov 23, 2016 at 01:09:20AM +0100, Tomas Hlavacek wrote:
> Turris Omnia board by CZ.NIC:
> 
>   * Marvell Armada 385 SoC
>   * 1 or 2 GB DDR3
>   * eMMC
>   * 8 MB SPI flash (U-Boot and rescue Linux image)
>   * 88E1514 PHY
>   * 88E6176 Ethernet switch (not supported)
> 
> Supported board revision: CZ11NIC13 (production board).
> 
> Signed-off-by: Tomas Hlavacek <tmshlvck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

As you picked my v3, you should keep my S-o-b.

> ---
> Changes since Uwe's version:
> 
> - add MBUS regions (needed for Marvell CESA)
> - remove rtc disable (WFM with CZ11NIC13 = production board)

If I do

	mw 0xf10184a0 0xfd4d4cfa

in the boot loader, it seems to work for me, too. You don't need that?

> - cleanup comments
> 
> Unsupported peripherals:
> - MV88E7176 switch
> - SFP
> - LEDs

LEDs is not that bad IMHO, because they work. You just cannot change
their function, but they blink according to their default trigger.
 
> ---
>  arch/arm/boot/dts/Makefile                    |   1 +
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
>  2 files changed, 280 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f1d3b9ff 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>  	armada-385-db-ap.dtb \
>  	armada-385-linksys-caiman.dtb \
>  	armada-385-linksys-cobra.dtb \
> +	armada-385-turris-omnia.dtb \
>  	armada-388-clearfog.dtb \
>  	armada-388-db.dtb \
>  	armada-388-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 0000000..5ef3d62
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
> + *
> + * Copyright (C) 2016 Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> + * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "armada-385.dtsi"
> +
> +/ {
> +	model = "Turris Omnia";
> +	compatible = "cznic,turris-omnia", "marvell,armada385", \
> +			"marvell,armada380";

You don't need a \ here AFAIK.

> +
> +	chosen {
> +		stdout-path = &uart0;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x40000000>; /* 1024 MB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> +			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> +
> +		internal-regs {
> +
> +			/* USB part of the PCIe2/USB 2.0 port */
> +			usb@58000 {
> +				status = "okay";
> +			};
> +
> +			sata@a8000 {
> +				status = "okay";
> +			};
> +
> +			sdhci@d8000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&sdhci_pins>;
> +				status = "okay";
> +
> +				bus-width = <8>;
> +				no-1-8-v;
> +				non-removable;
> +			};
> +
> +			usb3@f0000 {
> +				status = "okay";
> +			};
> +
> +			usb3@f8000 {
> +				status = "okay";
> +			};
> +		};
> +
> +		pcie-controller {
> +			status = "okay";
> +
> +			pcie@1,0 {
> +				/* Port 0, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie@2,0 {
> +				/* Port 1, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			pcie@3,0 {
> +				/* Port 2, Lane 0 */
> +				status = "okay";
> +			};
> +		};
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 6 */
> +&eth0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge0_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* Connected to 88E6176 switch, port 5 */
> +&eth1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ge1_rgmii_pins>;
> +	status = "okay";
> +	phy-mode = "rgmii-id";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> +
> +/* WAN port */
> +&eth2 {
> +	status = "okay";
> +	phy-mode = "sgmii";
> +	phy = <&phy1>;
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	i2cmux@70 {
> +		compatible = "nxp,pca9547";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		status = "okay";
> +
> +		i2c@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +			status = "okay";
> +
> +			/* STM32F0 command interface at address 0x2a.
> +			 * STM32F0 LED interface at address 0x2b.
> +			 */

Should this better be:

			/*
			 * STM32F0 command interface at address 0x2a.
			 * STM32F0 LED interface at address 0x2b.
			 */

As is recommended for comments in .c?

> +
> +			eeprom@54 {
> +				compatible = "at,24c64";
> +				reg = <0x54>;
> +
> +				/* The EEPROM contains data for bootloader.
> +				 * Contents:
> +				 *	struct omnia_eeprom {
> +				 *		u32 magic; (=0x0341a034)
> +				 *		u32 ramsize;
ramsize in GiB?

> +				 *		char region[4] (=0x0);
This is for the WLAN regdomain, right?

> +				 *		u32 crc32;
> +				 *	};
> +				 */
ditto for the comment format.

> +			};
> +		};
> +
> +		/* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> +		 * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> +		 * Channel 3: Routed to PCIe2 connector (CN62A).
> +		 * Channel 4: Routed to SFP+.
> +		 * Channel 5: ATSHA204A at address 0x64.
> +		 * Channel 6: Routed to user pin header CN11.
> +		 */
I'd like to keep the busses as Andrew already pointed out. For example
this might make it possible to use i2c-tools to read out the mac address
from the ATSHA.

> +		i2c@7 {
> +			/* GPIO expander for SFP+ signals */
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <7>;
> +
> +			wangpio: gpio@71 {
> +				compatible = "nxp,pca9538";
> +				reg = <0x71>;
> +				interrupt-parent = <&gpio1>;
> +				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +			};
> +		};
> +	};
> +};
> +
> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +	status = "okay";
> +
> +	phy1: phy@1 {
> +		status = "okay";
> +		compatible = "ethernet-phy-id0141.0DD1", \
> +				"ethernet-phy-ieee802.3-c22";

Drop the \

> +		reg = <1>;
> +		/* IRQ is connected to PCA9538 pin 7. Currently it
> +		 * can not be utilized.
> +		 */
> +	};
> +
> +	/* Switch MV88E7176 at address 0x10. */
> +};
> +
> +&pinctrl {
> +	spi0cs1_pins: spi0-pins-0cs1 {
> +		marvell,pins = "mpp26";
> +		marvell,function = "spi0";
> +	};

Why did you drop the pcawan pinctrl?

> +};
> +
> +&spi0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi0_pins &spi0cs1_pins>;

Oh, this is wrong (already in my patch): this is cs0 not cs1.

> +	status = "okay";
> +
> +	spi-nor@0 {
> +		compatible = "spansion,s25fl164k", "jedec,spi-nor";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0>;
> +		spi-max-frequency = <40000000>;
> +
> +		partition@0 {
> +			reg = <0x0 0x00100000>;
> +			label = "U-Boot";
> +		};
> +
> +		partition@1 {
> +			reg = <0x00100000 0x00700000>;
> +			label = "Rescue system";
> +		};
> +	};
> +
> +	/* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */

Looks strange. What about

	/* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */

Maybe also add the node for this pin to &pinctrl, but don't use it in
&spi0.pinctrl-0? This would nicely document the MPP26 part.

> +};
> +
> +&uart0 {
> +	/* Pin header CN10. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	/* Pin header CN11. */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>;
> +	status = "okay";
> +};
> +

Trailing new line

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek-x+rMaJPWets]

Hi Uwe!

On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> Anyway I took your patch and tried few things:
> - add pca9538 interrupt-controller
> - add IRQ for 88E1514 PHY - and there is a problem:
...

I thought it over and if I am not mistaken this is not going to work 
anyway, because pca9538 driver causes the GPIO driver to set 
IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander 
pins as IRQ source for 88E1514, because request_irq() on it will fail 
ultimately.

Tomas

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hi Uwe!

On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek at nic.cz wrote:
> Anyway I took your patch and tried few things:
> - add pca9538 interrupt-controller
> - add IRQ for 88E1514 PHY - and there is a problem:
...

I thought it over and if I am not mistaken this is not going to work 
anyway, because pca9538 driver causes the GPIO driver to set 
IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander 
pins as IRQ source for 88E1514, because request_irq() on it will fail 
ultimately.

Tomas

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

On Wed, Nov 23, 2016 at 01:27:31AM +0100, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> Hi Uwe!
> 
> On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> >Anyway I took your patch and tried few things:
> >- add pca9538 interrupt-controller
> >- add IRQ for 88E1514 PHY - and there is a problem:
> ...
> 
> I thought it over and if I am not mistaken this is not going to work
> anyway, because pca9538 driver causes the GPIO driver to set
> IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander
> pins as IRQ source for 88E1514, because request_irq() on it will
> fail ultimately.

Actually, the phylib now does uses threaded IRQs, since i implemented
interrupt support for the mv88e6xxx driver. Its interrupts require
MDIO transactions, so have to be threaded.

However, i don't think using interrupts on the pca9538 are
reliable. Interrupt support is compile time optional for that
driver. It is not clear to me if distributions do compile the driver
with interrupts enabled. So it could be the probe fails with OpenWRT,
Debian, etc...

	Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

On Wed, Nov 23, 2016 at 01:27:31AM +0100, tomas.hlavacek at nic.cz wrote:
> Hi Uwe!
> 
> On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek at nic.cz wrote:
> >Anyway I took your patch and tried few things:
> >- add pca9538 interrupt-controller
> >- add IRQ for 88E1514 PHY - and there is a problem:
> ...
> 
> I thought it over and if I am not mistaken this is not going to work
> anyway, because pca9538 driver causes the GPIO driver to set
> IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander
> pins as IRQ source for 88E1514, because request_irq() on it will
> fail ultimately.

Actually, the phylib now does uses threaded IRQs, since i implemented
interrupt support for the mv88e6xxx driver. Its interrupts require
MDIO transactions, so have to be threaded.

However, i don't think using interrupts on the pca9538 are
reliable. Interrupt support is compile time optional for that
driver. It is not clear to me if distributions do compile the driver
with interrupts enabled. So it could be the probe fails with OpenWRT,
Debian, etc...

	Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> >CZ11NIC12 is indicated on my board.
> 
> :-( Well, this board version has wrongly matched length of some
> differential pairs, IRQ from 88E1514 is connected differently, there
> are slight differences in power supplies and (if I am not mistaken)
> something changed in RTC support circuitry. It looks like a huge
> mistake on our side.

Hi Tomas

Would these problems also explain why the Ethernet links to the switch
don't work? Maybe the differential pairs?

> It seems that libphy is probed before pca9538 and we end up with:
> [    4.217550] libphy: orion_mdio_bus: probed
> [    4.221777] irq: no irq domain found for
> /soc/internal-regs/i2c@11000/i2cmux@70/i2c@7/gpio@71 !
> 
> Any clue where to look in order to defer probing libphy or at least
> orion_mdio_bus?

I think there is a known phylib problem here. Somewhere in the call
chain there is a void function, so the EPROBE_DEFFER gets
discarded. But i could be remembering this wrongly.

      Andrew

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Andrew Lunn]

> >CZ11NIC12 is indicated on my board.
> 
> :-( Well, this board version has wrongly matched length of some
> differential pairs, IRQ from 88E1514 is connected differently, there
> are slight differences in power supplies and (if I am not mistaken)
> something changed in RTC support circuitry. It looks like a huge
> mistake on our side.

Hi Tomas

Would these problems also explain why the Ethernet links to the switch
don't work? Maybe the differential pairs?

> It seems that libphy is probed before pca9538 and we end up with:
> [    4.217550] libphy: orion_mdio_bus: probed
> [    4.221777] irq: no irq domain found for
> /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
> 
> Any clue where to look in order to defer probing libphy or at least
> orion_mdio_bus?

I think there is a known phylib problem here. Somewhere in the call
chain there is a void function, so the EPROBE_DEFFER gets
discarded. But i could be remembering this wrongly.

      Andrew

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]

Hello Andrew,

On 11/23/2016 03:59 PM, Andrew Lunn wrote:
>>> CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
> 
> Hi Tomas
> 
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?

no this is not the problem. When booting the OpenWRT based system I can
communicate with the device via the switch. (Didn't test deeply, but my
Laptop got a dhcp lease from the Turris Omnia and I can ping it.) But
this convinces me, that the hardware is good enough.

If you have any ideas what I can try to make the switch work or help to
diagnose the problem, just let me know.

Best regards
Uwe


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH RFC] ARM: dts: add support for Turris Omnia

[Uwe Kleine-König]

Hello Andrew,

On 11/23/2016 03:59 PM, Andrew Lunn wrote:
>>> CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
> 
> Hi Tomas
> 
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?

no this is not the problem. When booting the OpenWRT based system I can
communicate with the device via the switch. (Didn't test deeply, but my
Laptop got a dhcp lease from the Turris Omnia and I can ping it.) But
this convinces me, that the hardware is good enough.

If you have any ideas what I can try to make the switch work or help to
diagnose the problem, just let me know.

Best regards
Uwe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161123/3b35fee8/attachment.sig>

Re: [PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek]

Hi Andrew!

On Wed, Nov 23, 2016 at 3:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  >CZ11NIC12 is indicated on my board.
>> 
>>  :-( Well, this board version has wrongly matched length of some
>>  differential pairs, IRQ from 88E1514 is connected differently, there
>>  are slight differences in power supplies and (if I am not mistaken)
>>  something changed in RTC support circuitry. It looks like a huge
>>  mistake on our side.
> 
> Hi Tomas
> 
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?

I do not think so. The ethernet links to the switch are RGMII, not 
differential pairs. Differential pair is used only for the eth2 to link 
either SFP+ or 88E1514 (via a high-speed switch that selects one or 
another). So the problems with differential pairs affect only WAN 
interface.

> 
> 
>>  It seems that libphy is probed before pca9538 and we end up with:
>>  [    4.217550] libphy: orion_mdio_bus: probed
>>  [    4.221777] irq: no irq domain found for
>>  /soc/internal-regs/i2c@11000/i2cmux@70/i2c@7/gpio@71 !
>> 
>>  Any clue where to look in order to defer probing libphy or at least
>>  orion_mdio_bus?
> 
> I think there is a known phylib problem here. Somewhere in the call
> chain there is a void function, so the EPROBE_DEFFER gets
> discarded. But i could be remembering this wrongly.

Oh yes, I thought that and I tried to find exactly this type of problem 
yesterday, but I didn't succeed. But I think that we agreed that we are 
going to stick with PHY polling rather then experimenting with 
unreliable IRQ over the GPIO expander, so we can leave this unresolved.

I will look into the I2C mux concerns, fix the remaining comments 
regarding my version and test RTC more extensively - Uwe's board is 
still not ticking, mine does, so we have to rule out that it is a 
common problem.

Tomas

[PATCH RFC] ARM: dts: add support for Turris Omnia

[tomas.hlavacek at nic.cz]

Hi Andrew!

On Wed, Nov 23, 2016 at 3:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  >CZ11NIC12 is indicated on my board.
>> 
>>  :-( Well, this board version has wrongly matched length of some
>>  differential pairs, IRQ from 88E1514 is connected differently, there
>>  are slight differences in power supplies and (if I am not mistaken)
>>  something changed in RTC support circuitry. It looks like a huge
>>  mistake on our side.
> 
> Hi Tomas
> 
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?

I do not think so. The ethernet links to the switch are RGMII, not 
differential pairs. Differential pair is used only for the eth2 to link 
either SFP+ or 88E1514 (via a high-speed switch that selects one or 
another). So the problems with differential pairs affect only WAN 
interface.

> 
> 
>>  It seems that libphy is probed before pca9538 and we end up with:
>>  [    4.217550] libphy: orion_mdio_bus: probed
>>  [    4.221777] irq: no irq domain found for
>>  /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
>> 
>>  Any clue where to look in order to defer probing libphy or at least
>>  orion_mdio_bus?
> 
> I think there is a known phylib problem here. Somewhere in the call
> chain there is a void function, so the EPROBE_DEFFER gets
> discarded. But i could be remembering this wrongly.

Oh yes, I thought that and I tried to find exactly this type of problem 
yesterday, but I didn't succeed. But I think that we agreed that we are 
going to stick with PHY polling rather then experimenting with 
unreliable IRQ over the GPIO expander, so we can leave this unresolved.

I will look into the I2C mux concerns, fix the remaining comments 
regarding my version and test RTC more extensively - Uwe's board is 
still not ticking, mine does, so we have to rule out that it is a 
common problem.

Tomas