Turris Omnia device-tree changes
v3 cover Turris Omnia device-tree changes
Hi Gregory,
v3 of series with changes for Turris Omnia device tree.
Changes since v2 (mostly thanks to Andreas):
- fixed typo in 2/7
- updated comment in 4/7 (describing current SFP cage binding status)
- changed commit message in 4/7 a little bit
- changed LED_FUNCTION_DEBUG to LED_FUNCTION_INDICATOR in 5/7
- updated comment about LED controller in 5/7
- added 7/7 which removes 2 unneeded status = "okay"
Changes since v1:
- added patch which adds description for switch interrupt
- removed patch adding ethernet-phy interrupt: the PHY interrupt is asserted by level low, but the GPIO expander driver supports only edge rising/falling, and even then it may not be correct when an interrupt storm occurs. So keep polling the PHY
- added Andrew's Reviewed-by tags
Marek Behún (7):
ARM: dts: turris-omnia: enable HW buffer management
ARM: dts: turris-omnia: add comphy handle to eth2
ARM: dts: turris-omnia: describe switch interrupt
ARM: dts: turris-omnia: add SFP node
ARM: dts: turris-omnia: add LED controller node
ARM: dts: turris-omnia: update ethernet-phy node and handle name
ARM: dts: turris-omnia: remove unneeded status = "okay" properties
arch/arm/boot/dts/armada-385-turris-omnia.dts | 178 +++++++++++++++++- 1 file changed, 170 insertions(+), 8 deletions(-)
Signature · 1 line
2.26.2
PATCH v3 1/7 ARM: dts: turris-omnia: enable HW buffer management
The buffer manager is available on Turris Omnia but needs to be described in device-tree to be used.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
arch/arm/boot/dts/armada-385-turris-omnia.dts +17 -0
@@ -84,12 +84,23 @@ pcie@3,0 { }; }; +&bm { + status = "okay"; +}; + +&bm_bppi { + status = "okay"; +}; + /* Connected to 88E6176 switch, port 6 */ ð0 { pinctrl-names = "default"; pinctrl-0 = <&ge0_rgmii_pins>; status = "okay"; phy-mode = "rgmii"; + buffer-manager = <&bm>; + bm,pool-long = <0>; + bm,pool-short = <3>; fixed-link { speed = <1000>;
@@ -103,6 +114,9 @@ ð1 { pinctrl-0 = <&ge1_rgmii_pins>; status = "okay"; phy-mode = "rgmii"; + buffer-manager = <&bm>; + bm,pool-long = <1>; + bm,pool-short = <3>; fixed-link { speed = <1000>;
@@ -115,6 +129,9 @@ ð2 { status = "okay"; phy-mode = "sgmii"; phy = <&phy1>; + buffer-manager = <&bm>; + bm,pool-long = <2>; + bm,pool-short = <3>; }; &i2c0 {
Signature · 1 line
2.26.2
PATCH v3 2/7 ARM: dts: turris-omnia: add comphy handle to eth2
In reply to Marek BehúnThe eth2 controller on Turris Omnia is connected to SerDes. For SFP to be able to switch between 1G and 2.5G modes the comphy link has to be defined.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/armada-385-turris-omnia.dts +1 -0
@@ -129,6 +129,7 @@ ð2 { status = "okay"; phy-mode = "sgmii"; phy = <&phy1>; + phys = <&comphy5 2>; buffer-manager = <&bm>; bm,pool-long = <2>; bm,pool-short = <3>;
Signature · 1 line
2.26.2
PATCH v3 3/7 ARM: dts: turris-omnia: describe switch interrupt
In reply to Marek BehúnDescribe switch interrupt for Turris Omnia so that the CPU does not have to poll the switch. We also need to to set mpp45 pin to gpio function for this.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +11 -1
@@ -260,13 +260,18 @@ phy1: phy@1 { /* Switch MV88E6176 at address 0x10 */ switch@10 { + pinctrl-names = "default"; + pinctrl-0 = <&swint_pins>; compatible = "marvell,mv88e6085"; #address-cells = <1>; #size-cells = <0>; - dsa,member = <0 0>; + dsa,member = <0 0>; reg = <0x10>; + interrupt-parent = <&gpio1>; + interrupts = <13 IRQ_TYPE_LEVEL_LOW>; + ports { #address-cells = <1>; #size-cells = <0>;
@@ -319,6 +324,11 @@ pcawan_pins: pcawan-pins { marvell,function = "gpio"; }; + swint_pins: swint-pins { + marvell,pins = "mpp45"; + marvell,function = "gpio"; + }; + spi0cs0_pins: spi0cs0-pins { marvell,pins = "mpp25"; marvell,function = "spi0";
Signature · 1 line
2.26.2
PATCH v3 4/7 ARM: dts: turris-omnia: add SFP node
In reply to Marek BehúnTurris Omnia has an SFP cage that, together with WAN PHY, is connected to eth2 SerDes via a SerDes multiplexor. When a SFP module is present, the multiplexor switches the SerDes signal from PHY to SFP.
Describe the SFP cage, but leave it disabled. Until phylink has support for such configuration, we are leaving it to U-Boot to enable SFP and disable WAN PHY at boot time depending on whether a SFP module is present.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 29 ++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +28 -1
@@ -82,6 +82,23 @@ pcie@3,0 { }; }; }; + + sfp: sfp { + compatible = "sff,sfp"; + i2c-bus = <&sfp_i2c>; + tx-fault-gpios = <&pcawan 0 GPIO_ACTIVE_HIGH>; + tx-disable-gpios = <&pcawan 1 GPIO_ACTIVE_HIGH>; + rate-select0-gpios = <&pcawan 2 GPIO_ACTIVE_HIGH>; + los-gpios = <&pcawan 3 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&pcawan 4 GPIO_ACTIVE_LOW>; + + /* + * For now this has to be enabled at boot time by U-Boot when + * a SFP module is present. Read more in the comment in the + * eth2 node below. + */ + status = "disabled"; + }; }; &bm {
@@ -126,10 +143,20 @@ fixed-link { /* WAN port */ ð2 { + /* + * eth2 is connected via a multiplexor to both the SFP cage and to + * ethernet-phy@1. The multiplexor switches the signal to SFP cage when + * a SFP module is present, as determined by the mode-def0 GPIO. + * + * Until kernel supports this configuration properly, in case SFP module + * is present, U-Boot has to enable the sfp node above, remove phy + * handle and add managed = "in-band-status" property. + */ status = "okay"; phy-mode = "sgmii"; phy = <&phy1>; phys = <&comphy5 2>; + sfp = <&sfp>; buffer-manager = <&bm>; bm,pool-long = <2>; bm,pool-short = <3>;
@@ -195,7 +222,7 @@ i2c@3 { /* routed to PCIe2 connector (CN62A) */ }; - i2c@4 { + sfp_i2c: i2c@4 { #address-cells = <1>; #size-cells = <0>; reg = <4>;
Signature · 1 line
2.26.2
PATCH v3 4/7 ARM: dts: turris-omnia: add SFP node
Turris Omnia has an SFP cage that, together with WAN PHY, is connected to eth2 SerDes via a SerDes multiplexor. When a SFP module is present, the multiplexor switches the SerDes signal from PHY to SFP.
Describe the SFP cage, but leave it disabled. Until phylink has support for such configuration, we are leaving it to U-Boot to enable SFP and disable WAN PHY at boot time depending on whether a SFP module is present.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 30 ++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +29 -1
@@ -82,6 +82,24 @@ pcie@3,0 { }; }; }; + + sfp: sfp { + compatible = "sff,sfp"; + i2c-bus = <&sfp_i2c>; + tx-fault-gpios = <&pcawan 0 GPIO_ACTIVE_HIGH>; + tx-disable-gpios = <&pcawan 1 GPIO_ACTIVE_HIGH>; + rate-select0-gpios = <&pcawan 2 GPIO_ACTIVE_HIGH>; + los-gpios = <&pcawan 3 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&pcawan 4 GPIO_ACTIVE_LOW>; + maximum-power-milliwatt = <3000>; + + /* + * For now this has to be enabled at boot time by U-Boot when + * a SFP module is present. Read more in the comment in the + * eth2 node below. + */ + status = "disabled"; + }; }; &bm {
@@ -126,10 +144,20 @@ fixed-link { /* WAN port */ ð2 { + /* + * eth2 is connected via a multiplexor to both the SFP cage and to + * ethernet-phy@1. The multiplexor switches the signal to SFP cage when + * a SFP module is present, as determined by the mode-def0 GPIO. + * + * Until kernel supports this configuration properly, in case SFP module + * is present, U-Boot has to enable the sfp node above, remove phy + * handle and add managed = "in-band-status" property. + */ status = "okay"; phy-mode = "sgmii"; phy = <&phy1>; phys = <&comphy5 2>; + sfp = <&sfp>; buffer-manager = <&bm>; bm,pool-long = <2>; bm,pool-short = <3>;
@@ -195,7 +223,7 @@ i2c@3 { /* routed to PCIe2 connector (CN62A) */ }; - i2c@4 { + sfp_i2c: i2c@4 { #address-cells = <1>; #size-cells = <0>; reg = <4>;
Signature · 1 line
2.26.2
Re: [PATCH mvebu-dt v3.1 4/7] ARM: dts: turris-omnia: add SFP node
On Mon, 16 Nov 2020 13:24:22 +0100
Marek Behún <[email protected]> wrote:
JFI, added
Quoted 1 line
maximum-power-milliwatt = <3000>;
since HW guys just confirmed this.
Marek
Re: [PATCH mvebu-dt v3.1 4/7] ARM: dts: turris-omnia: add SFP node
In reply to Marek BehúnQuoted 4 lines · Marek Behún
Describe the SFP cage, but leave it disabled. Until phylink has support for such configuration, we are leaving it to U-Boot to enable SFP and disable WAN PHY at boot time depending on whether a SFP module is present.
Let's be clear: this is _not_ something I have any plans to be working on adding; this is for others to get involved with.
I am not going to ack or review your patch to hack around this either.
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH mvebu-dt v3.1 4/7] ARM: dts: turris-omnia: add SFP node
Quoted 2 lines · On Mon, 16 Nov 2020 12:34:56 +0000 Russell King - ARM Linux admin…
Let's be clear: this is _not_ something I have any plans to be working on adding; this is for others to get involved with.
Russell, I consider this self-evident.
Since Turris Omnia is currently probably the only device with such configuration, it will be on me to add this support.
I will try to work out the correct solution and send patches for review.
For now though, lets merge this. It will simplify our (the vendor of the device) patching on TurrisOS.
Marek
PATCH v3 5/7 ARM: dts: turris-omnia: add LED controller node
In reply to Marek BehúnLinux now has incomplete support for the LED controller on Turris Omnia:
it can set brightness and colors for each LED.
The controller can also put these LEDs into HW controlled mode, in which the LEDs are controlled by HW: for example the WAN LED is connected via MCU to the WAN PHY LED pin.
The driver does not support these HW controlled modes yet, and on probe puts the LEDs into SW controlled mode.
Add node describing the LED controller, but disable it for now.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 111 +++++++++++++++++- 1 file changed, 110 insertions(+), 1 deletion(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +110 -1
@@ -12,6 +12,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/leds/common.h> #include "armada-385.dtsi" / {
@@ -180,7 +181,115 @@ i2c@0 { reg = <0>; /* STM32F0 command interface at address 0x2a */ - /* leds device (in STM32F0) at address 0x2b */ + + led-controller@2b { + compatible = "cznic,turris-omnia-leds"; + reg = <0x2b>; + #address-cells = <1>; + #size-cells = <0>; + + /* + * LEDs are controlled by MCU (STM32F0) at + * address 0x2b. + * + * The driver does not support HW control mode + * for the LEDs yet. Disable the LEDs for now. + * + * Also LED functions are not stable yet: + * - there are 3 LEDs connected via MCU to PCIe + * ports. One of these ports supports mSATA. + * There is no mSATA nor PCIe function. + * For now we use LED_FUNCTION_WLAN, since + * in most cases users have wifi cards in + * these slots + * - there are 2 LEDs dedicated for user: A and + * B. Again there is no such function defined. + * For now we use LED_FUNCTION_INDICATOR + */ + status = "disabled"; + + multi-led@0 { + reg = <0x0>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <2>; + }; + + multi-led@1 { + reg = <0x1>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <1>; + }; + + multi-led@2 { + reg = <0x2>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_WLAN; + function-enumerator = <3>; + }; + + multi-led@3 { + reg = <0x3>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_WLAN; + function-enumerator = <2>; + }; + + multi-led@4 { + reg = <0x4>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_WLAN; + function-enumerator = <1>; + }; + + multi-led@5 { + reg = <0x5>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_WAN; + }; + + multi-led@6 { + reg = <0x6>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_LAN; + function-enumerator = <4>; + }; + + multi-led@7 { + reg = <0x7>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_LAN; + function-enumerator = <3>; + }; + + multi-led@8 { + reg = <0x8>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_LAN; + function-enumerator = <2>; + }; + + multi-led@9 { + reg = <0x9>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_LAN; + function-enumerator = <1>; + }; + + multi-led@a { + reg = <0xa>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_LAN; + function-enumerator = <0>; + }; + + multi-led@b { + reg = <0xb>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_POWER; + }; + }; eeprom@54 { compatible = "atmel,24c64";
Signature · 1 line
2.26.2
PATCH v3 6/7 ARM: dts: turris-omnia: update ethernet-phy node and handle name
In reply to Marek BehúnUse property name phy-handle instead of the deprecated phy to connect eth2 to the PHY.
Rename the node from "phy@1" to "ethernet-phy@1", since "phy@1" is incorrect according to device-tree bindings documentation. Also remove the "ethernet-phy-id0141.0DD1" compatible string, it is not needed. Kernel can read the PHY identifier itself.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +3 -3
@@ -155,7 +155,7 @@ ð2 { */ status = "okay"; phy-mode = "sgmii"; - phy = <&phy1>; + phy-handle = <&phy1>; phys = <&comphy5 2>; sfp = <&sfp>; buffer-manager = <&bm>;
@@ -386,9 +386,9 @@ &mdio { pinctrl-0 = <&mdio_pins>; status = "okay"; - phy1: phy@1 { + phy1: ethernet-phy@1 { status = "okay"; - compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22"; + compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>; /* irq is connected to &pcawan pin 7 */
Signature · 1 line
2.26.2
PATCH v3 7/7 ARM: dts: turris-omnia: remove unneeded status = "okay" properties
In reply to Marek BehúnOnly nodes which have status = "disabled" defined from included files need status = "okay".
The ethernet-phy node and the i2cmux node do not need it, since they are wholly defined here.
--- arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 -- 1 file changed, 2 deletions(-)
arch/arm/boot/dts/armada-385-turris-omnia.dts +0 -2
@@ -173,7 +173,6 @@ i2cmux@70 { #address-cells = <1>; #size-cells = <0>; reg = <0x70>; - status = "okay"; i2c@0 { #address-cells = <1>;
@@ -387,7 +386,6 @@ &mdio { status = "okay"; phy1: ethernet-phy@1 { - status = "okay"; compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>;
Signature · 1 line
2.26.2
Hello Marek,
Quoted 3 lines
Hi Gregory,
v3 of series with changes for Turris Omnia device tree.
I applied the full series on mvebu/dt
Thanks,
Gregory
Quoted 41 lines
Changes since v2 (mostly thanks to Andreas):
- fixed typo in 2/7
- updated comment in 4/7 (describing current SFP cage binding status)
- changed commit message in 4/7 a little bit
- changedLED_FUNCTION_DEBUGtoLED_FUNCTION_INDICATORin 5/7
- updated comment about LED controller in 5/7
- added 7/7 which removes 2 unneeded status = "okay"Changes since v1:
- added patch which adds description for switch interrupt
- removed patch adding ethernet-phy interrupt: the PHY interrupt is asserted by level low, but the GPIO expander driver supports only edge rising/falling, and even then it may not be correct when an interrupt storm occurs. So keep polling the PHY
- added Andrew's Reviewed-by tagsCc Uwe Kleine-König <[email protected]>Cc Jason Cooper <[email protected]>Cc Gregory CLEMENT <[email protected]>Cc Andreas Färber <[email protected]>Cc Andrew Lunn <[email protected]>Cc Rob Herring <[email protected]>Marek Behún (7):
ARM: dts: turris-omnia: enable HW buffer management
ARM: dts: turris-omnia: add comphy handle to eth2
ARM: dts: turris-omnia: describe switch interrupt
ARM: dts: turris-omnia: add SFP node
ARM: dts: turris-omnia: add LED controller node
ARM: dts: turris-omnia: update ethernet-phy node and handle name
ARM: dts: turris-omnia: remove unneeded status = "okay" propertiesarch/arm/boot/dts/armada-385-turris-omnia.dts | 178 +++++++++++++++++- 1 file changed, 170 insertions(+), 8 deletions(-)Signature · 1 line
2.26.2
Signature · 3 lines
Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com