From: Peng Fan <peng.fan@nxp.com>
Add SCMI v3.2 pinctrl protocol bindings and example.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/firmware/arm,scmi.yaml | 99 ++++++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 4591523b51a0..bfd2b6a89979 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -247,6 +247,85 @@ properties:
reg:
const: 0x18
+ protocol@19:
+ type: object
+ allOf:
+ - $ref: '#/$defs/protocol-node'
+ - $ref: /schemas/pinctrl/pinctrl.yaml
+ - if:
+ properties:
+ compatible:
+ const: fsl,imx95-scmi-pinctrl
+ then:
+ patternProperties:
+ "grp$": false
+ "-pins$": true
+ else:
+ patternProperties:
+ "grp$": false
+ "-pins$": true
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x19
+
+ '#pinctrl-cells':
+ const: 0
+
+ compatible:
+ const: fsl,imx95-scmi-pinctrl
+
+ patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ unevaluatedProperties: false
+
+ description:
+ A pin multiplexing sub-node describe how to configure a
+ set of pins is some desired function.
+ A single sub-node may define several pin configurations.
+ This sub-node is using default pinctrl bindings to configure
+ pin multiplexing and using SCMI protocol to apply specified
+ configuration using SCMI protocol.
+
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>. The last
+ integer CONFIG is the pad setting value like pull-up on this pin. Please
+ refer to i.MX95 Plus Reference Manual for detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be applied.
+
+ required:
+ - reg
+
additionalProperties: false
$defs:
@@ -401,6 +480,26 @@ examples:
scmi_powercap: protocol@18 {
reg = <0x18>;
};
+
+ scmi_pinctrl: protocol@19 {
+ reg = <0x19>;
+ #pinctrl-cells = <0>;
+
+ i2c2-pins {
+ groups = "i2c2_a", "i2c2_b";
+ function = "i2c2";
+ };
+
+ mdio-pins {
+ groups = "avb_mdio";
+ drive-strength = <24>;
+ };
+
+ keys_pins: keys-pins {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
+ bias-pull-up;
+ };
+ };
};
};
--
2.37.1
On Fri, Dec 15, 2023 at 07:56:32PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > Add SCMI v3.2 pinctrl protocol bindings and example. > Hi as I mentioned on the last patch review, I dont see adding all this vendor specific stuff in the ARM SCMI Pinctrl generic binding as a viable option, nor the per-protocol compatible to select slightly different behaviours. Thanks, Cristian
Hi Peng,
On Fri, Dec 15, 2023 at 12:52 PM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
In this example, as it is not intended to reflect any specific hardware,
use the latest canonical naming:
> +
> + scmi_pinctrl: protocol@19 {
> + reg = <0x19>;
> + #pinctrl-cells = <0>;
> +
> + i2c2-pins {
> + groups = "i2c2_a", "i2c2_b";
groups = "g_i2c2_a", "g_i2c2_b";
> + function = "i2c2";
function = "f_i2c2";
> + };
> +
> + mdio-pins {
> + groups = "avb_mdio";
groups = "g_avb_mdio";
> + drive-strength = <24>;
> + };
> +
> + keys_pins: keys-pins {
> + pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
These names look odd to me, like these are actually groups
with pins 5..17 etc. Should it be groups = "g_gpio_5_17" etc?
Yours,
Linus Walleij
Hi Peng,
On 23-12-15, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add SCMI v3.2 pinctrl protocol bindings and example.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/firmware/arm,scmi.yaml | 99 ++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 4591523b51a0..bfd2b6a89979 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -247,6 +247,85 @@ properties:
> reg:
> const: 0x18
>
> + protocol@19:
...
> @@ -401,6 +480,26 @@ examples:
> scmi_powercap: protocol@18 {
> reg = <0x18>;
> };
> +
> + scmi_pinctrl: protocol@19 {
> + reg = <0x19>;
> + #pinctrl-cells = <0>;
> +
> + i2c2-pins {
> + groups = "i2c2_a", "i2c2_b";
> + function = "i2c2";
> + };
> +
> + mdio-pins {
> + groups = "avb_mdio";
> + drive-strength = <24>;
> + };
> +
> + keys_pins: keys-pins {
> + pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> + bias-pull-up;
> + };
> + };
This example is different to the one you mentioned within the
cover-letter. I didn't checked all patches just want to ask which API
will be implemented by this patchset?
Regards,
Marco
> };
> };
>
>
> --
> 2.37.1
>
>
>
On Fri, Dec 15, 2023 at 07:56:32PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add SCMI v3.2 pinctrl protocol bindings and example.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/firmware/arm,scmi.yaml | 99 ++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 4591523b51a0..bfd2b6a89979 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -247,6 +247,85 @@ properties:
> reg:
> const: 0x18
>
> + protocol@19:
> + type: object
> + allOf:
> + - $ref: '#/$defs/protocol-node'
> + - $ref: /schemas/pinctrl/pinctrl.yaml
> + - if:
> + properties:
> + compatible:
> + const: fsl,imx95-scmi-pinctrl
> + then:
> + patternProperties:
> + "grp$": false
> + "-pins$": true
> + else:
> + patternProperties:
> + "grp$": false
> + "-pins$": true
> + unevaluatedProperties: false
This will not scale if each vendor adds to arm,scmi.yaml. You need to
move this to its own file. That can have a ref to
/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node.
Here you can just say compatible is "fsl,imx95-scmi-pinctrl" and
'additionalProperties: true'.
> +
> + properties:
> + reg:
> + const: 0x19
> +
> + '#pinctrl-cells':
> + const: 0
Generally not used if 0.
> +
> + compatible:
> + const: fsl,imx95-scmi-pinctrl
> +
> + patternProperties:
> + '-pins$':
> + type: object
> + allOf:
> + - $ref: /schemas/pinctrl/pincfg-node.yaml#
> + - $ref: /schemas/pinctrl/pinmux-node.yaml#
> + unevaluatedProperties: false
> +
> + description:
> + A pin multiplexing sub-node describe how to configure a
> + set of pins is some desired function.
> + A single sub-node may define several pin configurations.
> + This sub-node is using default pinctrl bindings to configure
> + pin multiplexing and using SCMI protocol to apply specified
> + configuration using SCMI protocol.
> +
> + 'grp$':
> + type: object
> + description:
> + Pinctrl node's client devices use subnodes for desired pin configuration.
> + Client device subnodes use below standard properties.
> +
> + properties:
> + fsl,pins:
> + description:
> + each entry consists of 6 integers and represents the mux and config
> + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
> + mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
> + be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>. The last
> + integer CONFIG is the pad setting value like pull-up on this pin. Please
> + refer to i.MX95 Plus Reference Manual for detailed CONFIG settings.
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + items:
> + items:
> + - description: |
> + "mux_reg" indicates the offset of mux register.
> + - description: |
> + "conf_reg" indicates the offset of pad configuration register.
> + - description: |
> + "input_reg" indicates the offset of select input register.
> + - description: |
> + "mux_val" indicates the mux value to be applied.
> + - description: |
> + "input_val" indicates the select input value to be applied.
> + - description: |
> + "pad_setting" indicates the pad configuration value to be applied.
> +
> + required:
> + - reg
> +
> additionalProperties: false
>
> $defs:
> @@ -401,6 +480,26 @@ examples:
> scmi_powercap: protocol@18 {
> reg = <0x18>;
> };
> +
> + scmi_pinctrl: protocol@19 {
> + reg = <0x19>;
> + #pinctrl-cells = <0>;
Missing compatible. Schema should catch that...
> +
> + i2c2-pins {
> + groups = "i2c2_a", "i2c2_b";
> + function = "i2c2";
> + };
> +
> + mdio-pins {
> + groups = "avb_mdio";
> + drive-strength = <24>;
> + };
> +
> + keys_pins: keys-pins {
> + pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> + bias-pull-up;
> + };
> + };
> };
> };
>
>
> --
> 2.37.1
>
© 2016 - 2025 Red Hat, Inc.