Hi Jacopo,
On Mon, Aug 24, 2020 at 11:09 AM Jacopo Mondi <jacopo@xxxxxxxxxx> wrote:
> On Fri, Aug 21, 2020 at 01:19:56PM +0200, Geert Uytterhoeven wrote:
> > Convert the Renesas RZ/A1 combined Pin and GPIO controller Device Tree
> > binding documentation to json-schema.
> >
> > Rename "rza1-pinctrl" to "rza1-ports", to match the compatible value
> > scheme.
> > Use "pinctrl" generic node name.
> > Drop generic and consumer examples, as they do not belong here.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
> > + properties:
> > + gpio-controller: true
> > +
> > + '#gpio-cells':
> > + const: 2
> > +
> > + gpio-ranges:
> > + maxItems: 1
> > +
> > + required:
> > + - gpio-controller
>
> Doesn't 'true' imply required ?
No, true means that a property for which the schema is declared
elsewhere is applicable here.
> > + - '#gpio-cells'
> > + - gpio-ranges
> > +
> > +
> > +additionalProperties:
> > + anyOf:
>
> Confused by this part. This describes a GPIO consumer, doesn't it ?
> Does this part belong here ?
It describes the ping multiplexing sub-node, as a child (first item of
anOf), or grandchild (second item of anyOf).
> > + - type: object
> > + allOf:
> > + - $ref: pincfg-node.yaml#
> > + - $ref: pinmux-node.yaml#
> > +
> > + description:
> > + A pin multiplexing sub-node describes how to configure a set of (or a
> > + single) pin in some desired alternate function mode.
> > + A single sub-node may define several pin configurations.
> > + A few alternate function require special pin configuration flags to be
> > + supplied along with the alternate function configuration number.
> > + The hardware reference manual specifies when a pin function requires
> > + "software IO driven" mode to be specified. To do so use the generic
> > + properties from the <include/linux/pinctrl/pinconf_generic.h> header
> > + file to instruct the pin controller to perform the desired pin
> > + configuration operation.
> > + The hardware reference manual specifies when a pin has to be configured
> > + to work in bi-directional mode and when the IO direction has to be
> > + specified by software. Bi-directional pins must be managed by the pin
> > + controller driver internally, while software driven IO direction has to
> > + be explicitly selected when multiple options are available.
> > +
> > + properties:
> > + pinmux:
> > + description: |
> > + Integer array representing pin number and pin multiplexing
> > + configuration.
> > + When a pin has to be configured in alternate function mode, use
> > + this property to identify the pin by its global index, and provide
> > + its alternate function configuration number along with it.
> > + When multiple pins are required to be configured as part of the
> > + same alternate function they shall be specified as members of the
> > + same argument list of a single "pinmux" property.
> > + Helper macros to ease assembling the pin index from its position
> > + (port where it sits on and pin number) and alternate function
> > + identifier are provided by the pin controller header file at:
> > + <include/dt-bindings/pinctrl/r7s72100-pinctrl.h>
> > + Integers values in "pinmux" argument list are assembled as:
> > + ((PORT * 16 + PIN) | MUX_FUNC << 16)
> > +
> > + phandle: true
> > + input-enable: true
> > + output-enable: true
> > +
> > + required:
> > + - pinmux
> > +
> > + additionalProperties: false
> > +
> > + - type: object
> > + properties:
> > + phandle: true
> > +
> > + additionalProperties:
> > + $ref: "#/additionalProperties/anyOf/0"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
