* [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux @ 2017-03-03 20:59 Xo Wang 2017-03-07 21:13 ` Rick Altherr 0 siblings, 1 reply; 7+ messages in thread From: Xo Wang @ 2017-03-03 20:59 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-03 20:59 [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux Xo Wang @ 2017-03-07 21:13 ` Rick Altherr 2017-03-07 21:19 ` Xo Wang 0 siblings, 1 reply; 7+ messages in thread From: Rick Altherr @ 2017-03-07 21:13 UTC (permalink / raw) To: Xo Wang; +Cc: OpenBMC Maillist 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-07 21:13 ` Rick Altherr @ 2017-03-07 21:19 ` Xo Wang 2017-03-07 21:21 ` Rick Altherr 0 siblings, 1 reply; 7+ messages in thread From: Xo Wang @ 2017-03-07 21:19 UTC (permalink / raw) To: Rick Altherr; +Cc: OpenBMC Maillist 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-07 21:19 ` Xo Wang @ 2017-03-07 21:21 ` Rick Altherr 2017-03-07 21:31 ` Xo Wang 0 siblings, 1 reply; 7+ messages in thread From: Rick Altherr @ 2017-03-07 21:21 UTC (permalink / raw) To: Xo Wang; +Cc: OpenBMC Maillist 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-07 21:21 ` Rick Altherr @ 2017-03-07 21:31 ` Xo Wang 2017-03-07 21:32 ` Rick Altherr 0 siblings, 1 reply; 7+ messages in thread From: Xo Wang @ 2017-03-07 21:31 UTC (permalink / raw) To: Rick Altherr; +Cc: OpenBMC Maillist 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-07 21:31 ` Xo Wang @ 2017-03-07 21:32 ` Rick Altherr 2017-03-07 22:02 ` Xo Wang 0 siblings, 1 reply; 7+ messages in thread From: Rick Altherr @ 2017-03-07 21:32 UTC (permalink / raw) To: Xo Wang, Maxim Sloyko; +Cc: OpenBMC Maillist +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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux 2017-03-07 21:32 ` Rick Altherr @ 2017-03-07 22:02 ` Xo Wang 0 siblings, 0 replies; 7+ messages in thread From: Xo Wang @ 2017-03-07 22:02 UTC (permalink / raw) To: Rick Altherr; +Cc: Maxim Sloyko, OpenBMC Maillist 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-07 22:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-03 20:59 [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux Xo Wang 2017-03-07 21:13 ` Rick Altherr 2017-03-07 21:19 ` Xo Wang 2017-03-07 21:21 ` Rick Altherr 2017-03-07 21:31 ` Xo Wang 2017-03-07 21:32 ` Rick Altherr 2017-03-07 22:02 ` Xo Wang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.