On Thu, Oct 21, 2021 at 7:42 PM Emil Renner Berthing <kernel@xxxxxxxx> wrote: > Add bindings for the StarFive JH7100 GPIO/pin controller. > > Signed-off-by: Emil Renner Berthing <kernel@xxxxxxxx> That is a very terse commit message for an entirely new SoC, please put a little blurb about this silicon there. Like mention that it is RISC-V at least. Overall quite interesting! > +$id: http://devicetree.org/schemas/pinctrl/starfive,jh7100-pinctrl.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: StarFive JH7100 Pin Controller Device Tree Bindings > + > +maintainers: > + - Emil Renner Berthing <kernel@xxxxxxxx> > + - Drew Fustini <drew@xxxxxxxxxxxxxxx> Add description: talking about that this is a RISC-V SoC and other implicit things that are really good to know. > + starfive,signal-group: > + description: | > + The SoC has a global setting selecting one of 7 different pinmux > + configurations of the pads named GPIO[0:63] and FUNC_SHARE[0:141]. After > + this global setting is chosen only the 64 "GPIO" pins can be further > + muxed by configuring them to be controlled by certain peripherals rather > + than software. > + Note that in configuration 0 none of GPIOs are routed to pads, and only > + in configuration 1 are the GPIOs routed to the pads named GPIO[0:63]. > + If this property is not set it defaults to the configuration already > + chosen by the earlier boot stages. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2, 3, 4, 5, 6] This still is hard for me to understand. Does it mean that 0..6 define how the direct-to-peripheral-pins are set up? Then it would make sense to describe what happens for 0, 1, 2 ...6 i.e. what the different set-ups are. Actually this is what we call group-based pin multiplexing in Linux, this property seems to avoid using that concept. See for example: Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt > + patternProperties: > + '-pins*$': > + type: object > + description: | > + A pinctrl node should contain at least one subnode representing the > + pinctrl groups available on the machine. Each subnode will list the > + pins it needs, and how they should be configured, with regard to > + muxer configuration, bias, input enable/disable, input schmitt > + trigger enable/disable, slew-rate and drive strength. > + $ref: "/schemas/pinctrl/pincfg-node.yaml" Nice that you use pincfg-node.yaml > + properties: > + pins: > + description: | > + The list of pin identifiers that properties in the node apply to. > + This should be set using either the PAD_GPIO or PAD_FUNC_SHARE > + macro. Either this or "pinmux" has to be specified. > + > + pinmux: > + description: | > + The list of GPIO identifiers and their mux settings that > + properties in the node apply to. This should be set using the > + GPIOMUX macro. Either this or "pins" has to be specified. What about referencing Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml for this? Yours, Linus Walleij
