[PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[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 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

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[Rick Altherr]

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
>

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[Xo Wang]

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

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[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.

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

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[Xo Wang]

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

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[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.

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

Re: [PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[Xo Wang]

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