[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL_JsqJHoOU3M7ZUrpi8OH+0_5u0LOoYZeXEk08tFjf6fByncA@mail.gmail.com>
Date: Thu, 25 Aug 2022 13:53:01 -0500
From: Rob Herring <robh@...nel.org>
To: Jonas Gorski <jonas.gorski@...il.com>
Cc: Rafał Miłecki <rafal@...ecki.pl>,
Linus Walleij <linus.walleij@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Fernández Rojas <noltari@...il.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] dt-bindings: pinctrl: brcm: Ensure all child node
properties are documented
On Thu, Aug 25, 2022 at 10:23 AM Jonas Gorski <jonas.gorski@...il.com> wrote:
>
> On Tue, 16 Aug 2022 at 20:39, Rob Herring <robh@...nel.org> wrote:
> >
> > The Broadcom pinctrl bindings are incomplete for child nodes as they are
> > missing 'unevaluatedProperties: false' to prevent unknown properties.
> > Fixing this reveals many warnings including having grandchild nodes in some
> > cases.
> >
> > Signed-off-by: Rob Herring <robh@...nel.org>
> > ---
> > This recursive schema requires a fix not yet committed in dtschema.
> >
> > I'm looking for feedback on whether group->pins or group->groups is the
> > right fix here. There's more warnings with this change in the gpio-sysctl
> > bindings.
>
> The answer is "yes", though pins is probably the closest for most.
>
> bcm6318 has multiple field-per-pin registers, where each pin is
> controlled separately, with more fields than available GPIOs, and the
> pins outside the GPIO range controlling other functions, like
> switching the second USB port between host and client mode.
>
> bcm6328/6362/6368/63268 have two registers. The first one enables an
> alternative function for the first 32 GPIOs, with a 1:1 mapping of
> bits to GPIO. The second one enables a function for whole, arbitrary
> groups. These groups can overlap, and may also target pins outside the
> first 32 GPIOs. The actual pins in use are not documented, and can
> sometimes be guessed/inferred by the function names (e.g. "GPIO35"),
> sometimes not ("NAND", "UTOPIA").
>
> bcm6358 has only the groups register, which also includes non GPIO
> related functions, like inversing the MII clocks for the integrated
> macs.
>
> Not supported is bcm6348, which would be the only one where groups
> would definitely make more sense: there are 5 groups of 8 GPIOs, where
> each group can be set to a certain function (but not all functions are
> valid for all groups). E.g. for PCI support, you would need to set the
> fields to PCI for groups 0, 1 and 3 (and 2 and 5 could be set to a
> different function). You can ignore this though, as bcm6348 is ancient
> (doesn't even support ADSL2+).
>
> Hope that helps a bit.
Only in determining that someone else needs to fix this. Please send me patches.
Rob
Powered by blists - more mailing lists