[PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux
xow at google.com
Wed Mar 8 09:02:34 AEDT 2017
On Tue, Mar 7, 2017 at 1:32 PM, Rick Altherr <raltherr at google.com> wrote:
> 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 at google.com> wrote:
>> On Tue, Mar 7, 2017 at 1:21 PM, Rick Altherr <raltherr at 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 at google.com> wrote:
>>>> On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr at 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
>> 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.
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).
More information about the openbmc