lkml.org 
[lkml]   [2021]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 11/16] dt-bindings: pinctrl: Add StarFive JH7100 bindings
On Thu, Oct 21, 2021 at 7:42 PM Emil Renner Berthing <kernel@esmil.dk> wrote:

> Add bindings for the StarFive JH7100 GPIO/pin controller.
>
> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>

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@esmil.dk>
> + - Drew Fustini <drew@beagleboard.org>

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

\
 
 \ /
  Last update: 2021-10-25 01:12    [W:0.407 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site