| Message ID | 20170303205920.146751-1-xow@google.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
Why is Linux doing this instead of U-Boot? On Fri, Mar 3, 2017 at 12:59 PM, Xo Wang <xow@google.com> wrote: > 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. > > Signed-off-by: Xo Wang <xow@google.com> > --- > arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > index dc0546869886..3bd70ed810af 100644 > --- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts > @@ -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 >
On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr@google.com> wrote: > 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. On Tue, Mar 7, 2017 at 1:19 PM, Xo Wang <xow@google.com> wrote: > On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr@google.com> wrote: >> 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
On Tue, Mar 7, 2017 at 1:21 PM, Rick Altherr <raltherr@google.com> wrote: > I don't believe it currently does. I'm concerned with whether U-Boot > or Linux is expected to configure the NC-SI muxes. > > On Tue, Mar 7, 2017 at 1:19 PM, Xo Wang <xow@google.com> wrote: >> On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr@google.com> wrote: >>> 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. On Tue, Mar 7, 2017 at 1:31 PM, Xo Wang <xow@google.com> wrote: > On Tue, Mar 7, 2017 at 1:21 PM, Rick Altherr <raltherr@google.com> wrote: >> I don't believe it currently does. I'm concerned with whether U-Boot >> or Linux is expected to configure the NC-SI muxes. >> >> On Tue, Mar 7, 2017 at 1:19 PM, Xo Wang <xow@google.com> wrote: >>> On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr@google.com> wrote: >>>> 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
On Tue, Mar 7, 2017 at 1:32 PM, Rick Altherr <raltherr@google.com> wrote: > +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. > > On Tue, Mar 7, 2017 at 1:31 PM, Xo Wang <xow@google.com> wrote: >> On Tue, Mar 7, 2017 at 1:21 PM, Rick Altherr <raltherr@google.com> wrote: >>> I don't believe it currently does. I'm concerned with whether U-Boot >>> or Linux is expected to configure the NC-SI muxes. >>> >>> On Tue, Mar 7, 2017 at 1:19 PM, Xo Wang <xow@google.com> wrote: >>>> On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr@google.com> wrote: >>>>> 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
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts index dc0546869886..3bd70ed810af 100644 --- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts +++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts @@ -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>;
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. Signed-off-by: Xo Wang <xow@google.com> --- arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 7 +++++++ 1 file changed, 7 insertions(+)