| Message ID | 20211021174223.43310-12-kernel@esmil.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Basic StarFive JH7100 RISC-V SoC support | expand |
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
On Mon, 25 Oct 2021 at 01:11, Linus Walleij <linus.walleij@linaro.org> wrote: > 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. Will do! > 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. Gotcha. > > + 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? Yeah, so the SoC has many pins, but only the pins named GPIO[0:63] and FUNC_SHARE[0:141] can be muxed. To do that you first select one of 7 different "signal groups". This is a global setting. There is just a single register on the whole SoC where you write either 0, 1, .., or 6. As an example signal group 6 maps LCD output to FUNC_SHARE[40:97], ethernet phy connection to FUNC_SHARE[115:141], MIPI to GPIO[0:60] and confusingly it maps "GPIO0", "GPIO1", ..., "GPIO63" to pins FUNC_SHARE[0:63]. So the pin names doesn't necessarily match the function. In fact only signal group 1 maps GPIO0-63 to pins GPIO[0:63]. See table 11-1 starting on page 62 of this PDF: https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf GPIO0-63 can of course be used as GPIOs, but they can also have their output value and output enable controlled by certain (slow) peripherals like UARTs, I2C, SPI, PWM etc. These can be chosen freely. So once you've chosen signal group 6, you can have any of GPIO0-GPIO63 (that is any of pins FUNC_SHARE[0:63]) be controlled by the UART0 TX signal fx. So for each of GPIO0 to GPIO63 there is a register to select the output value signal and a register to select its output enable signal. You can see the list of signals to choose from in the header introduced in the previous patch. Input from GPIO0-63 to peripherals works the other way around. Here there is a register for each input signal, where you can select which (if any) of GPIO0-63 is routed to the peripheral. > Then it would make sense to describe what happens for 0, 1, 2 ...6 > i.e. what the different set-ups are. Yeah, so how much of table 11-1 does it make sense to write out. Certainly I can list how GPIO0-63 are mapped to pins for each of the 7 signal groups, but should I also list LCD, ethernet, interconnect, mipi etc. for each of the 7 signal groups? > 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 I don't think this is the same, but hope you can tell me after reading the description above. > > + 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? Sure. You just mean adding $ref: like above right? Thanks! /Emil
On Thu, Oct 21, 2021 at 07:42:18PM +0200, Emil Renner Berthing wrote: > Add bindings for the StarFive JH7100 GPIO/pin controller. > > Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> > --- > .../pinctrl/starfive,jh7100-pinctrl.yaml | 274 ++++++++++++++++++ > 1 file changed, 274 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml > > diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml > new file mode 100644 > index 000000000000..342ecd91a3b0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml > @@ -0,0 +1,274 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$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> > + > +properties: > + compatible: > + const: starfive,jh7100-pinctrl > + > + reg: > + minItems: 2 > + maxItems: 2 > + > + reg-names: > + items: > + - const: "gpio" > + - const: "padctl" Don't need quotes. > + > + clocks: > + maxItems: 1 > + > + resets: > + maxItems: 1 > + > + gpio-controller: true > + > + "#gpio-cells": > + const: 2 > + description: | > + Number of cells in GPIO specifier. Since the generic GPIO > + binding is used, the amount of cells must be specified as 2. > + > + interrupts: > + maxItems: 1 > + description: The GPIO parent interrupt. > + > + interrupt-controller: true > + > + "#interrupt-cells": > + const: 2 > + > + 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] > + > +required: > + - compatible > + - reg > + - reg-names > + - clocks > + - gpio-controller > + - "#gpio-cells" > + - interrupts > + - interrupt-controller > + - "#interrupt-cells" > + > +patternProperties: > + '-[0-9]*$': Can you make this more specific. As-is, '-' and 'foo-' are valid. > + type: object > + patternProperties: > + '-pins*$': So foo-pinsssssss is okay? Drop the '*' or use ? if you intend to support 'foo-pin'. > + 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" > + > + 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. > + > + bias-disable: true > + > + bias-pull-up: > + type: boolean Already has a type. Need to reference the common schema. > + > + bias-pull-down: > + type: boolean > + > + drive-strength: > + enum: [ 14, 21, 28, 35, 42, 49, 56, 63 ] > + > + input-enable: true > + > + input-disable: true > + > + input-schmitt-enable: true > + > + input-schmitt-disable: true > + > + slew-rate: > + maximum: 7 > + > + starfive,strong-pull-up: > + description: enable strong pull-up. > + type: boolean > + > + additionalProperties: false > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/starfive-jh7100.h> > + #include <dt-bindings/reset/starfive-jh7100.h> > + #include <dt-bindings/pinctrl/pinctrl-starfive.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + gpio: pinctrl@11910000 { > + compatible = "starfive,jh7100-pinctrl"; > + reg = <0x0 0x11910000 0x0 0x10000>, > + <0x0 0x11858000 0x0 0x1000>; > + reg-names = "gpio", "padctl"; > + clocks = <&clkgen JH7100_CLK_GPIO_APB>; > + resets = <&clkgen JH7100_RSTN_GPIO_APB>; > + interrupts = <32>; > + gpio-controller; > + #gpio-cells = <2>; > + interrupt-controller; > + #interrupt-cells = <2>; > + starfive,signal-group = <6>; > + > + gmac_pins_default: gmac-0 { > + gtxclk-pins { > + pins = <PAD_FUNC_SHARE(115)>; > + bias-pull-up; > + drive-strength = <35>; > + input-enable; > + input-schmitt-enable; > + slew-rate = <0>; > + }; > + miitxclk-pins { > + pins = <PAD_FUNC_SHARE(116)>; > + bias-pull-up; > + drive-strength = <14>; > + input-enable; > + input-schmitt-disable; > + slew-rate = <0>; > + }; > + tx-pins { > + pins = <PAD_FUNC_SHARE(117)>, > + <PAD_FUNC_SHARE(119)>, > + <PAD_FUNC_SHARE(120)>, > + <PAD_FUNC_SHARE(121)>, > + <PAD_FUNC_SHARE(122)>, > + <PAD_FUNC_SHARE(123)>, > + <PAD_FUNC_SHARE(124)>, > + <PAD_FUNC_SHARE(125)>, > + <PAD_FUNC_SHARE(126)>; > + bias-disable; > + drive-strength = <35>; > + input-disable; > + input-schmitt-disable; > + slew-rate = <0>; > + }; > + rxclk-pins { > + pins = <PAD_FUNC_SHARE(127)>; > + bias-pull-up; > + drive-strength = <14>; > + input-enable; > + input-schmitt-disable; > + slew-rate = <6>; > + }; > + rxer-pins { > + pins = <PAD_FUNC_SHARE(129)>; > + bias-pull-up; > + drive-strength = <14>; > + input-enable; > + input-schmitt-disable; > + slew-rate = <0>; > + }; > + rx-pins { > + pins = <PAD_FUNC_SHARE(128)>, > + <PAD_FUNC_SHARE(130)>, > + <PAD_FUNC_SHARE(131)>, > + <PAD_FUNC_SHARE(132)>, > + <PAD_FUNC_SHARE(133)>, > + <PAD_FUNC_SHARE(134)>, > + <PAD_FUNC_SHARE(135)>, > + <PAD_FUNC_SHARE(136)>, > + <PAD_FUNC_SHARE(137)>, > + <PAD_FUNC_SHARE(138)>, > + <PAD_FUNC_SHARE(139)>, > + <PAD_FUNC_SHARE(140)>, > + <PAD_FUNC_SHARE(141)>; > + bias-pull-up; > + drive-strength = <14>; > + input-enable; > + input-schmitt-enable; > + slew-rate = <0>; > + }; > + }; > + > + i2c0_pins_default: i2c0-0 { > + i2c-pins { > + pinmux = <GPIOMUX(62, GPO_LOW, > + GPO_I2C0_PAD_SCK_OEN, > + GPI_I2C0_PAD_SCK_IN)>, > + <GPIOMUX(61, GPO_LOW, > + GPO_I2C0_PAD_SDA_OEN, > + GPI_I2C0_PAD_SDA_IN)>; > + bias-disable; /* external pull-up */ > + input-enable; > + input-schmitt-enable; > + }; > + }; > + > + uart3_pins_default: uart3-0 { > + rx-pin { > + pinmux = <GPIOMUX(13, GPO_LOW, GPO_DISABLE, > + GPI_UART3_PAD_SIN)>; > + bias-pull-up; > + input-enable; > + input-schmitt-enable; > + }; > + tx-pin { > + pinmux = <GPIOMUX(14, GPO_UART3_PAD_SOUT, > + GPO_ENABLE, GPI_NONE)>; > + bias-disable; > + input-disable; > + input-schmitt-disable; > + }; > + }; > + }; > + > + gmac { > + pinctrl-0 = <&gmac_pins_default>; > + pinctrl-names = "default"; > + }; > + > + i2c0 { > + pinctrl-0 = <&i2c0_pins_default>; > + pinctrl-names = "default"; > + }; > + > + uart3 { > + pinctrl-0 = <&uart3_pins_default>; > + pinctrl-names = "default"; > + }; > + }; > + > +... > -- > 2.33.1 > >
On Fri, 29 Oct 2021 at 03:50, Rob Herring <robh@kernel.org> wrote: > On Thu, Oct 21, 2021 at 07:42:18PM +0200, Emil Renner Berthing wrote: > > +patternProperties: > > + '-[0-9]*$': > > Can you make this more specific. As-is, '-' and 'foo-' are valid. > > > + type: object > > + patternProperties: > > + '-pins*$': > > So foo-pinsssssss is okay? Drop the '*' or use ? if you intend to > support 'foo-pin'. Ah, thanks. Both this and the pattern above was taken from pinctrl/mediatek,mt6779-pinctrl.yaml if anyone feels like fixing that too. I see now that '-[0-9]+$' and '-pins$' is more common. I'll just use that. > > + 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" > > + > > + 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. > > + > > + bias-disable: true > > + > > + bias-pull-up: > > + type: boolean > > Already has a type. Need to reference the common schema. Right, but the common schema specifies one of boolean or uint32. Is there a way to reference that, but still say that this binding supports only the boolean version?
On Fri, Oct 29, 2021 at 8:00 AM Emil Renner Berthing <kernel@esmil.dk> wrote: > > On Fri, 29 Oct 2021 at 03:50, Rob Herring <robh@kernel.org> wrote: > > On Thu, Oct 21, 2021 at 07:42:18PM +0200, Emil Renner Berthing wrote: > > > +patternProperties: > > > + '-[0-9]*$': > > > > Can you make this more specific. As-is, '-' and 'foo-' are valid. > > > > > + type: object > > > + patternProperties: > > > + '-pins*$': > > > > So foo-pinsssssss is okay? Drop the '*' or use ? if you intend to > > support 'foo-pin'. > > Ah, thanks. Both this and the pattern above was taken from > pinctrl/mediatek,mt6779-pinctrl.yaml if anyone feels like fixing that > too. I see now that '-[0-9]+$' and '-pins$' is more common. I'll just > use that. > > > > + 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" > > > + > > > + 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. > > > + > > > + bias-disable: true > > > + > > > + bias-pull-up: > > > + type: boolean > > > > Already has a type. Need to reference the common schema. > > Right, but the common schema specifies one of boolean or uint32. Is > there a way to reference that, but still say that this binding > supports only the boolean version? Okay, then keep this. Rob
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml new file mode 100644 index 000000000000..342ecd91a3b0 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml @@ -0,0 +1,274 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$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> + +properties: + compatible: + const: starfive,jh7100-pinctrl + + reg: + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: "gpio" + - const: "padctl" + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. + + interrupts: + maxItems: 1 + description: The GPIO parent interrupt. + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + 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] + +required: + - compatible + - reg + - reg-names + - clocks + - gpio-controller + - "#gpio-cells" + - interrupts + - interrupt-controller + - "#interrupt-cells" + +patternProperties: + '-[0-9]*$': + type: object + 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" + + 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. + + bias-disable: true + + bias-pull-up: + type: boolean + + bias-pull-down: + type: boolean + + drive-strength: + enum: [ 14, 21, 28, 35, 42, 49, 56, 63 ] + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + slew-rate: + maximum: 7 + + starfive,strong-pull-up: + description: enable strong pull-up. + type: boolean + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive-jh7100.h> + #include <dt-bindings/reset/starfive-jh7100.h> + #include <dt-bindings/pinctrl/pinctrl-starfive.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + gpio: pinctrl@11910000 { + compatible = "starfive,jh7100-pinctrl"; + reg = <0x0 0x11910000 0x0 0x10000>, + <0x0 0x11858000 0x0 0x1000>; + reg-names = "gpio", "padctl"; + clocks = <&clkgen JH7100_CLK_GPIO_APB>; + resets = <&clkgen JH7100_RSTN_GPIO_APB>; + interrupts = <32>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + starfive,signal-group = <6>; + + gmac_pins_default: gmac-0 { + gtxclk-pins { + pins = <PAD_FUNC_SHARE(115)>; + bias-pull-up; + drive-strength = <35>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + miitxclk-pins { + pins = <PAD_FUNC_SHARE(116)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + tx-pins { + pins = <PAD_FUNC_SHARE(117)>, + <PAD_FUNC_SHARE(119)>, + <PAD_FUNC_SHARE(120)>, + <PAD_FUNC_SHARE(121)>, + <PAD_FUNC_SHARE(122)>, + <PAD_FUNC_SHARE(123)>, + <PAD_FUNC_SHARE(124)>, + <PAD_FUNC_SHARE(125)>, + <PAD_FUNC_SHARE(126)>; + bias-disable; + drive-strength = <35>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + rxclk-pins { + pins = <PAD_FUNC_SHARE(127)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <6>; + }; + rxer-pins { + pins = <PAD_FUNC_SHARE(129)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + rx-pins { + pins = <PAD_FUNC_SHARE(128)>, + <PAD_FUNC_SHARE(130)>, + <PAD_FUNC_SHARE(131)>, + <PAD_FUNC_SHARE(132)>, + <PAD_FUNC_SHARE(133)>, + <PAD_FUNC_SHARE(134)>, + <PAD_FUNC_SHARE(135)>, + <PAD_FUNC_SHARE(136)>, + <PAD_FUNC_SHARE(137)>, + <PAD_FUNC_SHARE(138)>, + <PAD_FUNC_SHARE(139)>, + <PAD_FUNC_SHARE(140)>, + <PAD_FUNC_SHARE(141)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + }; + + i2c0_pins_default: i2c0-0 { + i2c-pins { + pinmux = <GPIOMUX(62, GPO_LOW, + GPO_I2C0_PAD_SCK_OEN, + GPI_I2C0_PAD_SCK_IN)>, + <GPIOMUX(61, GPO_LOW, + GPO_I2C0_PAD_SDA_OEN, + GPI_I2C0_PAD_SDA_IN)>; + bias-disable; /* external pull-up */ + input-enable; + input-schmitt-enable; + }; + }; + + uart3_pins_default: uart3-0 { + rx-pin { + pinmux = <GPIOMUX(13, GPO_LOW, GPO_DISABLE, + GPI_UART3_PAD_SIN)>; + bias-pull-up; + input-enable; + input-schmitt-enable; + }; + tx-pin { + pinmux = <GPIOMUX(14, GPO_UART3_PAD_SOUT, + GPO_ENABLE, GPI_NONE)>; + bias-disable; + input-disable; + input-schmitt-disable; + }; + }; + }; + + gmac { + pinctrl-0 = <&gmac_pins_default>; + pinctrl-names = "default"; + }; + + i2c0 { + pinctrl-0 = <&i2c0_pins_default>; + pinctrl-names = "default"; + }; + + uart3 { + pinctrl-0 = <&uart3_pins_default>; + pinctrl-names = "default"; + }; + }; + +...
Add bindings for the StarFive JH7100 GPIO/pin controller. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> --- .../pinctrl/starfive,jh7100-pinctrl.yaml | 274 ++++++++++++++++++ 1 file changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml