ARM: dts: aspeed: zaius: Enable NC-SI mux
Subsystems (2)
PATCH 1/1 ARM: dts: aspeed: zaius: Enable NC-SI mux
The Zaius motherboard has muxes for the RMII lines from the BMC to:
- BCM5719 LAN on motherboard (LOM)
- OCP mezzanine connector
- HDMI form factor connector
Assert the active-low enable line for the muxes. Due to the AST2500 default internal pull-down resistors, the muxes selection lines will be low. This implicitly selects the LOM for NC-SI.
The NC-SI interface will show up as network interface eth0.
--- arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts +7 -0
@@ -325,6 +325,13 @@ line-name = "iso_u164_en"; }; + ncsi_mux_en_n { + gpio-hog; + gpios = <ASPEED_GPIO(P, 0) GPIO_ACTIVE_HIGH>; + output-low; + line-name = "ncsi_mux_en_n"; + }; + line_bmc_i2c2_sw_rst_n { gpio-hog; gpios = <ASPEED_GPIO(P, 1) GPIO_ACTIVE_HIGH>;
Signature · 1 line
2.12.0.rc1.440.g5b76565f74-goog
Why is Linux doing this instead of U-Boot?
Quoted 37 lines · Xo Wang
The Zaius motherboard has muxes for the RMII lines from the BMC to:
- BCM5719 LAN on motherboard (LOM)
- OCP mezzanine connector
- HDMI form factor connectorAssert the active-low enable line for the muxes. Due to the AST2500 default internal pull-down resistors, the muxes selection lines will be low. This implicitly selects the LOM for NC-SI.
The NC-SI interface will show up as network interface eth0.
Signed-off-by Xo Wang <[email protected]>--- arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts +7
-1@@ -325,6 +325,13 @@ line-name = "iso_u164_en"; }; + ncsi_mux_en_n { + gpio-hog; + gpios = <ASPEED_GPIO(P, 0) GPIO_ACTIVE_HIGH>; + output-low; + line-name = "ncsi_mux_en_n"; + }; + line_bmc_i2c2_sw_rst_n { gpio-hog; gpios = <ASPEED_GPIO(P, 1) GPIO_ACTIVE_HIGH>; --2.12.0.rc1.440.g5b76565f74-goog
Quoted 2 lines · Rick Altherr
Why is Linux doing this instead of U-Boot?
Does our U-Boot understand Aspeed GPIO in the device tree? If it does, then it makes more sense for U-Boot to consume and set these pin assignments.
xo
I don't believe it currently does. I'm concerned with whether U-Boot or Linux is expected to configure the NC-SI muxes.
Quoted 9 lines · Xo Wang
Quoted 2 lines · Rick Altherr
Why is Linux doing this instead of U-Boot?
Does our U-Boot understand Aspeed GPIO in the device tree? If it does, then it makes more sense for U-Boot to consume and set these pin assignments.
xo
Quoted 13 lines · Rick Altherr
I don't believe it currently does. I'm concerned with whether U-Boot or Linux is expected to configure the NC-SI muxes.
Quoted 9 lines · Xo Wang
Quoted 2 lines · Rick Altherr
Why is Linux doing this instead of U-Boot?
Does our U-Boot understand Aspeed GPIO in the device tree? If it does, then it makes more sense for U-Boot to consume and set these pin assignments.
xo
I would think U-Boot is expected to, since that provides the option of netbooting from the NC-SI adapter in U-Boot.
In addition, the Linux ftgmac100 driver can't yet handle the NC-SI mux changing dynamically (https://github.com/openbmc/openbmc/issues/979).
So for now the mux must be enabled and selected prior to that driver probing. This is the only reason why this assignment exists as a Linux
gpio-hog: it is set prior to any other driver being probed.
xo
+maxim
Sounds like U-Boot needs to do some work here. I'm unclear if the hog is necessary once U-Boot does the right thing.
Quoted 25 lines · Xo Wang
Quoted 13 lines · Rick Altherr
I don't believe it currently does. I'm concerned with whether U-Boot or Linux is expected to configure the NC-SI muxes.
Quoted 9 lines · Xo Wang
Quoted 2 lines · Rick Altherr
Why is Linux doing this instead of U-Boot?
Does our U-Boot understand Aspeed GPIO in the device tree? If it does, then it makes more sense for U-Boot to consume and set these pin assignments.
xo
I would think U-Boot is expected to, since that provides the option of netbooting from the NC-SI adapter in U-Boot.
In addition, the Linux ftgmac100 driver can't yet handle the NC-SI mux changing dynamically (https://github.com/openbmc/openbmc/issues/979).
So for now the mux must be enabled and selected prior to that driver probing. This is the only reason why this assignment exists as a Linux
gpio-hog: it is set prior to any other driver being probed.xo
Quoted 31 lines · Rick Altherr
+maxim
Sounds like U-Boot needs to do some work here. I'm unclear if the hog is necessary once U-Boot does the right thing.
Quoted 25 lines · Xo Wang
Quoted 13 lines · Rick Altherr
I don't believe it currently does. I'm concerned with whether U-Boot or Linux is expected to configure the NC-SI muxes.
Quoted 9 lines · Xo Wang
Quoted 2 lines · Rick Altherr
Why is Linux doing this instead of U-Boot?
Does our U-Boot understand Aspeed GPIO in the device tree? If it does, then it makes more sense for U-Boot to consume and set these pin assignments.
xo
I would think U-Boot is expected to, since that provides the option of netbooting from the NC-SI adapter in U-Boot.
In addition, the Linux ftgmac100 driver can't yet handle the NC-SI mux changing dynamically (https://github.com/openbmc/openbmc/issues/979).
So for now the mux must be enabled and selected prior to that driver probing. This is the only reason why this assignment exists as a Linux
gpio-hog: it is set prior to any other driver being probed.xo
The hog would be no longer necessary once U-Boot sets it. In fact, eliminating it is desirable because it opens up the possibility of changing the mux selection at runtime (gpio-hogs are write-once as far as I understand and preclude sysfs export for the GPIOs they occupy).
xo