Add the dt-bindings for the NXP SIUL2 module which is a multi
function device. It can export information about the SoC, configure
the pinmux&pinconf for pins and it is also a GPIO controller with
interrupt capability.
Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
---
.../bindings/mfd/nxp,s32g2-siul2.yaml | 165 ++++++++++++++++++
1 file changed, 165 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
diff --git a/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml b/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
new file mode 100644
index 000000000000..a8edbea75bb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,s32g2-siul2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32 System Integration Unit Lite2 (SIUL2)
+
+maintainers:
+ - Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
+
+description: |
+ SIUL2 is a hardware block which implements pinmuxing,
+ pinconf, GPIOs (some with interrupt capability) and
+ registers which contain information about the SoC.
+ There are generally two SIUL2 modules whose functionality
+ is grouped together. For example interrupt configuration
+ registers are part of SIUL2_1 even though interrupts are
+ also available for SIUL2_0 pins.
+
+ The following register types are exported by SIUL2:
+ - MIDR (MCU ID Register) - information related to the SoC
+ - interrupt configuration registers
+ - MSCR (Multiplexed Signal Configuration Register) - pinmuxing and pinconf
+ - IMCR (Input Multiplexed Signal Configuration Register)- pinmuxing
+ - PGPDO (Parallel GPIO Pad Data Out Register) - GPIO output value
+ - PGPDI (Parallel GPIO Pad Data In Register) - GPIO input value
+
+ Most registers are 32bit wide with the exception of PGPDO/PGPDI which are
+ 16bit wide.
+
+properties:
+ compatible:
+ enum:
+ - nxp,s32g2-siul2
+ - nxp,s32g3-siul2
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: siul20
+ - const: siul21
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ maxItems: 2
+
+ gpio-reserved-ranges:
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+ description:
+ This container may reference an NVMEM layout parser.
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ required:
+ - gpio-hog
+
+ "-pins$":
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "-grp[0-9]$":
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ description:
+ Pinctrl node's client devices specify pin muxes using subnodes,
+ which in turn use the standard properties below.
+
+ properties:
+ bias-disable: true
+ bias-high-impedance: true
+ bias-pull-up: true
+ bias-pull-down: true
+ drive-open-drain: true
+ input-enable: true
+ output-enable: true
+
+ pinmux:
+ description: |
+ An integer array for representing pinmux configurations of
+ a device. Each integer consists of a PIN_ID and a 4-bit
+ selected signal source(SSS) as IOMUX setting, which is
+ calculated as: pinmux = (PIN_ID << 4 | SSS)
+
+ slew-rate:
+ description: Supported slew rate based on Fmax values (MHz)
+ enum: [83, 133, 150, 166, 208]
+ required:
+ - pinmux
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+ - gpio-reserved-ranges
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ siul2@4009c000 {
+ compatible = "nxp,s32g2-siul2";
+ reg = <0x4009c000 0x179c>,
+ <0x44010000 0x17b0>;
+ reg-names = "siul20", "siul21";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&siul2 0 0 102>, <&siul2 112 112 79>;
+ gpio-reserved-ranges = <102 10>, <123 21>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
+
+ jtag_pins: jtag-pins {
+ jtag-grp0 {
+ pinmux = <0x0>;
+ input-enable;
+ bias-pull-up;
+ slew-rate = <166>;
+ };
+ };
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ soc-major@0 {
+ reg = <0 0x4>;
+ };
+ };
+ };
+...
--
2.45.2On 13/11/2024 11:10, Andrei Stefanescu wrote:
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,s32g2-siul2
> + - nxp,s32g3-siul2
Not much improved. See other NXP bindings how they do this.
> +
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: siul20
> + - const: siul21
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> + gpio-ranges:
> + maxItems: 2
> +
> + gpio-reserved-ranges:
> + maxItems: 2
That's odd to always require two reserved ranges. Does this mean all
devices have exactly the same reserved GPIOs? Then the driver should not
export them.
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
> + description:
> + This container may reference an NVMEM layout parser.
> +
> +patternProperties:
> + "-hog(-[0-9]+)?$":
> + required:
> + - gpio-hog
> +
> + "-pins$":
> + type: object
> + additionalProperties: false
> +
> + patternProperties:
> + "-grp[0-9]$":
> + type: object
> + allOf:
> + - $ref: /schemas/pinctrl/pinmux-node.yaml#
> + - $ref: /schemas/pinctrl/pincfg-node.yaml#
> + description:
> + Pinctrl node's client devices specify pin muxes using subnodes,
> + which in turn use the standard properties below.
> +
> + properties:
> + bias-disable: true
> + bias-high-impedance: true
> + bias-pull-up: true
> + bias-pull-down: true
> + drive-open-drain: true
> + input-enable: true
> + output-enable: true
> +
> + pinmux:
> + description: |
> + An integer array for representing pinmux configurations of
> + a device. Each integer consists of a PIN_ID and a 4-bit
> + selected signal source(SSS) as IOMUX setting, which is
> + calculated as: pinmux = (PIN_ID << 4 | SSS)
> +
> + slew-rate:
> + description: Supported slew rate based on Fmax values (MHz)
> + enum: [83, 133, 150, 166, 208]
> + required:
> + - pinmux
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - gpio-controller
> + - "#gpio-cells"
> + - gpio-ranges
> + - gpio-reserved-ranges
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + siul2@4009c000 {
<form letter>
This is a friendly reminder during the review process.
It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.
Thank you.
</form letter>
Best regards,
Krzysztof
Hi Krzysztof, Thank you for your review! On 19/11/2024 11:21, Krzysztof Kozlowski wrote: > On 13/11/2024 11:10, Andrei Stefanescu wrote: >> + >> +properties: >> + compatible: >> + enum: >> + - nxp,s32g2-siul2 >> + - nxp,s32g3-siul2 > > Not much improved. See other NXP bindings how they do this. > Do you mean to have the "nxp,s32g3-siul2" compatible fall back to the g2 one? >> + >> + gpio-reserved-ranges: >> + maxItems: 2 > > That's odd to always require two reserved ranges. Does this mean all > devices have exactly the same reserved GPIOs? Then the driver should not > export them. Yes, the driver exports GPIOs from two hardware modules because they are tightly coupled. I export two gpio-ranges, each one corresponding to a hardware module. If I were to export more gpio-ranges, thus avoiding gpio-reserved-ranges, it would be hard to know to which hardware module a gpio-range belongs. I would like to keep the current implementation regarding this problem. Would that be ok? > > <form letter> > This is a friendly reminder during the review process. > > It seems my or other reviewer's previous comments were not fully > addressed. Maybe the feedback got lost between the quotes, maybe you > just forgot to apply it. Please go back to the previous discussion and > either implement all requested changes or keep discussing them. > > Thank you. > </form letter> Yes, sorry for this. I initially thought you were referring to the label name. I now realize that I misread it. It will be changed to pinctrl in the next version. > > > > Best regards, > Krzysztof > Best regards, Andrei
On Tue, Nov 19, 2024 at 11:44:23AM +0200, Andrei Stefanescu wrote: > Hi Krzysztof, > > Thank you for your review! > > On 19/11/2024 11:21, Krzysztof Kozlowski wrote: > > On 13/11/2024 11:10, Andrei Stefanescu wrote: > >> + > >> +properties: > >> + compatible: > >> + enum: > >> + - nxp,s32g2-siul2 > >> + - nxp,s32g3-siul2 > > > > Not much improved. See other NXP bindings how they do this. > > > > Do you mean to have the "nxp,s32g3-siul2" compatible fall back to the g2 one? Yes, compatibility between devices means fallback. > > >> + > >> + gpio-reserved-ranges: > >> + maxItems: 2 > > > > That's odd to always require two reserved ranges. Does this mean all > > devices have exactly the same reserved GPIOs? Then the driver should not > > export them. > > Yes, the driver exports GPIOs from two hardware modules because they are > tightly coupled. I export two gpio-ranges, each one corresponding to a > hardware module. If I were to export more gpio-ranges, thus avoiding > gpio-reserved-ranges, it would be hard to know to which hardware module > a gpio-range belongs. I would like to keep the current implementation > regarding this problem. Would that be ok? I don't understand why this is needed then. If you always export same set of GPIOs, why do you export something which is unusable/reserved? Best regards, Krzysztof
Hi Krzysztof, >>>> + >>>> + gpio-reserved-ranges: >>>> + maxItems: 2 Would it be better if I removed the maxItems constraint? Looking at it now, I think it should rather be minItems: 2 in order to allow the user to further remove other GPIOs. >>> >>> That's odd to always require two reserved ranges. Does this mean all >>> devices have exactly the same reserved GPIOs? Then the driver should not >>> export them. >> >> Yes, the driver exports GPIOs from two hardware modules because they are >> tightly coupled. I export two gpio-ranges, each one corresponding to a >> hardware module. If I were to export more gpio-ranges, thus avoiding >> gpio-reserved-ranges, it would be hard to know to which hardware module >> a gpio-range belongs. I would like to keep the current implementation >> regarding this problem. Would that be ok? > > I don't understand why this is needed then. If you always export same > set of GPIOs, why do you export something which is unusable/reserved? > I will detail a bit about SIUL2 GPIO ranges here: SIUL2_0 exports GPIOs 0 - 101 SIUL2_1 exports GPIOs 112 - 122 and 144 - 190 Therefore, we have two gaps: 102 - 111 and 123 - 143. This applies for both S32G2 and S32G3 SoCs. AFAIK the only ways to exclude GPIOs from being exported are the following: - split the gpio-ranges property so it doesn't include those GPIOs I thought about doing this but I think this would involve other vendor specific properties in order to know the memory region to use for each GPIO range. Currently, we have two GPIO ranges and each one maps to its respective SIUL2 module. - using gpio-reserved-ranges which is my current approach because, in my opinion, it is the simplest approach. - registering multiple gpio_chips I know this approach is used when dealing with multiple banks. However, I think GPIO banks would rather apply to SIUL2 modules and not to our valid GPIO ranges. What are your thoughts about this? Best regards, Andrei
On Wed, Nov 13, 2024 at 12:10:53PM +0200, Andrei Stefanescu wrote:
> Add the dt-bindings for the NXP SIUL2 module which is a multi
> function device. It can export information about the SoC, configure
> the pinmux&pinconf for pins and it is also a GPIO controller with
> interrupt capability.
>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> ---
> .../bindings/mfd/nxp,s32g2-siul2.yaml | 165 ++++++++++++++++++
> 1 file changed, 165 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml b/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
> new file mode 100644
> index 000000000000..a8edbea75bb6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/nxp,s32g2-siul2.yaml
> @@ -0,0 +1,165 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2024 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/nxp,s32g2-siul2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP S32 System Integration Unit Lite2 (SIUL2)
> +
> +maintainers:
> + - Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> +
> +description: |
> + SIUL2 is a hardware block which implements pinmuxing,
> + pinconf, GPIOs (some with interrupt capability) and
> + registers which contain information about the SoC.
> + There are generally two SIUL2 modules whose functionality
> + is grouped together. For example interrupt configuration
> + registers are part of SIUL2_1 even though interrupts are
> + also available for SIUL2_0 pins.
> +
> + The following register types are exported by SIUL2:
> + - MIDR (MCU ID Register) - information related to the SoC
> + - interrupt configuration registers
> + - MSCR (Multiplexed Signal Configuration Register) - pinmuxing and pinconf
> + - IMCR (Input Multiplexed Signal Configuration Register)- pinmuxing
> + - PGPDO (Parallel GPIO Pad Data Out Register) - GPIO output value
> + - PGPDI (Parallel GPIO Pad Data In Register) - GPIO input value
> +
> + Most registers are 32bit wide with the exception of PGPDO/PGPDI which are
> + 16bit wide.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,s32g2-siul2
> + - nxp,s32g3-siul2
> +
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: siul20
> + - const: siul21
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> + gpio-ranges:
> + maxItems: 2
> +
> + gpio-reserved-ranges:
> + maxItems: 2
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
> + description:
> + This container may reference an NVMEM layout parser.
> +
> +patternProperties:
> + "-hog(-[0-9]+)?$":
> + required:
> + - gpio-hog
> +
> + "-pins$":
> + type: object
> + additionalProperties: false
> +
> + patternProperties:
> + "-grp[0-9]$":
> + type: object
> + allOf:
> + - $ref: /schemas/pinctrl/pinmux-node.yaml#
> + - $ref: /schemas/pinctrl/pincfg-node.yaml#
> + description:
> + Pinctrl node's client devices specify pin muxes using subnodes,
> + which in turn use the standard properties below.
> +
> + properties:
> + bias-disable: true
> + bias-high-impedance: true
> + bias-pull-up: true
> + bias-pull-down: true
> + drive-open-drain: true
> + input-enable: true
> + output-enable: true
> +
> + pinmux:
> + description: |
> + An integer array for representing pinmux configurations of
> + a device. Each integer consists of a PIN_ID and a 4-bit
> + selected signal source(SSS) as IOMUX setting, which is
> + calculated as: pinmux = (PIN_ID << 4 | SSS)
> +
> + slew-rate:
> + description: Supported slew rate based on Fmax values (MHz)
> + enum: [83, 133, 150, 166, 208]
> + required:
> + - pinmux
> +
> + additionalProperties: false
There are $ref, need use unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - gpio-controller
> + - "#gpio-cells"
> + - gpio-ranges
> + - gpio-reserved-ranges
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + siul2@4009c000 {
generic node name, such as 'pinctrl'
> + compatible = "nxp,s32g2-siul2";
> + reg = <0x4009c000 0x179c>,
> + <0x44010000 0x17b0>;
> + reg-names = "siul20", "siul21";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&siul2 0 0 102>, <&siul2 112 112 79>;
> + gpio-reserved-ranges = <102 10>, <123 21>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
> +
> + jtag_pins: jtag-pins {
needn't lable 'jtag_pins' in example.
> + jtag-grp0 {
> + pinmux = <0x0>;
> + input-enable;
> + bias-pull-up;
> + slew-rate = <166>;
> + };
> + };
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + soc-major@0 {
> + reg = <0 0x4>;
> + };
> + };
> + };
> +...
> --
> 2.45.2
>
© 2016 - 2024 Red Hat, Inc.