1. Add header file with constants for RMIO function IDs for the Rockchip
RK3506 SoC.
2. Add device tree binding for the RMIO (Rockchip Matrix I/O) controller
which is a sub-device of the main pinctrl on some Rockchip SoCs.

Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com>
---
 .../bindings/pinctrl/rockchip,pinctrl.yaml    |   9 ++
 .../bindings/pinctrl/rockchip,rmio.yaml       | 106 +++++++++++++++++
 .../pinctrl/rockchip,rk3506-rmio.h            | 109 ++++++++++++++++++
 3 files changed, 224 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
 create mode 100644 include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h

diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
index 97960245676d..9a27eaf7942b 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
@@ -82,6 +82,15 @@ required:
   - rockchip,grf
 
 patternProperties:
+  "rmio[0-9]*$":
+    type: object
+
+    $ref: "/schemas/pinctrl/rockchip,rmio.yaml#"
+
+    description:
+      The RMIO (Rockchip Matrix I/O) controller node which functions as a
+      sub-device of the main pinctrl to handle flexible function routing.
+
   "gpio@[0-9a-f]+$":
     type: object
 
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
new file mode 100644
index 000000000000..af0b34512fb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/rockchip,rmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RMIO (Rockchip Matrix I/O) Controller
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+description: |
+  The RMIO controller provides a flexible routing matrix that allows mapping
+  various internal peripheral functions (UART, SPI, PWM, etc.) to specific
+  physical pins. This block is typically a sub-block of the GRF
+  (General Register Files) or PMU (Power Management Unit).
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - rockchip,rk3506-rmio
+      - const: rockchip,rmio
+
+  rockchip,rmio-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      The phandle of the syscon node (GRF or PMU) containing the RMIO registers.
+      This property is required if the RMIO registers are located in a different
+      syscon than the parent pinctrl node.
+
+  rockchip,offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The offset of the RMIO configuration registers within the GRF.
+
+  rockchip,pins-num:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The number of physical pins supported by this RMIO instance.
+      Used for boundary checking and driver initialization.
+
+patternProperties:
+  "^[a-z0-9-]+$":
+    type: object
+    description:
+      Function node grouping multiple groups.
+
+    patternProperties:
+      "^[a-z0-9-]+$":
+        type: object
+        description:
+          Group node containing the pinmux configuration.
+
+        properties:
+          rockchip,rmio:
+            $ref: /schemas/types.yaml#/definitions/uint32-matrix
+            description:
+              A list of pin-function pairs. The format is <pin_id function_id>.
+            minItems: 1
+            items:
+              items:
+                - description: RMIO Pin ID (0 to pins-num - 1)
+                  minimum: 0
+                  maximum: 31
+                - description: Function ID
+                  minimum: 0
+                  maximum: 98
+
+        required:
+          - rockchip,rmio
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - rockchip,rmio-grf
+  - rockchip,offset
+  - rockchip,pins-num
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/pinctrl/rockchip,rk3506-rmio.h>
+
+    pinctrl: pinctrl {
+        rmio: rmio {
+            compatible = "rockchip,rk3506-rmio", "rockchip,rmio";
+            rockchip,rmio-grf = <&grf_pmu>;
+            rockchip,offset = <0x80>;
+            rockchip,pins-num = <32>;
+
+            rmio-uart {
+                rmio_pin27_uart1_tx: rmio-pin27-uart1-tx {
+                    rockchip,rmio = <27 RMIO_UART1_TX>;
+                };
+
+                rmio_pin28_uart1_rx: rmio-pin28-uart1-rx {
+                    rockchip,rmio = <28 RMIO_UART1_RX>;
+                };
+            };
+        };
+    };
diff --git a/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
new file mode 100644
index 000000000000..b129e9a8c287
--- /dev/null
+++ b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
@@ -0,0 +1,109 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
+#define __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
+
+/* RMIO function definition */
+#define RMIO_UART1_TX			1
+#define RMIO_UART1_RX			2
+#define RMIO_UART2_TX			3
+#define RMIO_UART2_RX			4
+#define RMIO_UART3_TX			5
+#define RMIO_UART3_RX			6
+#define RMIO_UART3_CTSN			7
+#define RMIO_UART3_RTSN			8
+#define RMIO_UART4_TX			9
+#define RMIO_UART4_RX			10
+#define RMIO_UART4_CTSN			11
+#define RMIO_UART4_RTSN			12
+#define RMIO_MIPITE			13
+#define RMIO_CLK_32K			14
+#define RMIO_I2C0_SCL			15
+#define RMIO_I2C0_SDA			16
+#define RMIO_I2C1_SCL			17
+#define RMIO_I2C1_SDA			18
+#define RMIO_I2C2_SCL			19
+#define RMIO_I2C2_SDA			20
+#define RMIO_PDM_CLK0			21
+#define RMIO_PDM_SDI0			22
+#define RMIO_PDM_SDI1			23
+#define RMIO_PDM_SDI2			24
+#define RMIO_PDM_SDI3			25
+#define RMIO_CAN1_TX			26
+#define RMIO_CAN1_RX			27
+#define RMIO_CAN0_TX			28
+#define RMIO_CAN0_RX			29
+#define RMIO_PWM0_CH0			30
+#define RMIO_PWM0_CH1			31
+#define RMIO_PWM0_CH2			32
+#define RMIO_PWM0_CH3			33
+#define RMIO_PWM1_CH0			34
+#define RMIO_PWM1_CH1			35
+#define RMIO_PWM1_CH2			36
+#define RMIO_PWM1_CH3			37
+#define RMIO_PWM1_CH4			38
+#define RMIO_PWM1_CH5			39
+#define RMIO_PWM1_CH6			40
+#define RMIO_PWM1_CH7			41
+#define RMIO_TOUCH_KEY_DRIVE		42
+#define RMIO_TOUCH_KEY_IN0		43
+#define RMIO_TOUCH_KEY_IN1		44
+#define RMIO_TOUCH_KEY_IN2		45
+#define RMIO_TOUCH_KEY_IN3		46
+#define RMIO_TOUCH_KEY_IN4		47
+#define RMIO_TOUCH_KEY_IN5		48
+#define RMIO_TOUCH_KEY_IN6		49
+#define RMIO_TOUCH_KEY_IN7		50
+#define RMIO_SAI0_MCLK			51
+#define RMIO_SAI0_SCLK			52
+#define RMIO_SAI0_LRCK			53
+#define RMIO_SAI0_SDI0			54
+#define RMIO_SAI0_SDI1			55
+#define RMIO_SAI0_SDI2			56
+#define RMIO_SAI0_SDI3			57
+#define RMIO_SAI0_SDO			58
+#define RMIO_SAI1_MCLK			59
+#define RMIO_SAI1_SCLK			60
+#define RMIO_SAI1_LRCK			61
+#define RMIO_SAI1_SDI			62
+#define RMIO_SAI1_SDO0			63
+#define RMIO_SAI1_SDO1			64
+#define RMIO_SAI1_SDO2			65
+#define RMIO_SAI1_SDO3			66
+#define RMIO_SPI0_CLK			67
+#define RMIO_SPI0_MOSI			68
+#define RMIO_SPI0_MISO			69
+#define RMIO_SPI0_CSN0			70
+#define RMIO_SPI0_CSN1			71
+#define RMIO_SPI1_CLK			72
+#define RMIO_SPI1_MOSI			73
+#define RMIO_SPI1_MISO			74
+#define RMIO_SPI1_CSN0			75
+#define RMIO_SPI1_CSN1			76
+#define RMIO_WDT_TSADC_SHUT		77
+#define RMIO_PMU_SLEEP			78
+#define RMIO_CORE_POWER_OFF		79
+#define RMIO_SPDIF_TX			80
+#define RMIO_SPDIF_RX			81
+#define RMIO_PWM1_BIP_CNTR_A0		82
+#define RMIO_PWM1_BIP_CNTR_A1		83
+#define RMIO_PWM1_BIP_CNTR_A2		84
+#define RMIO_PWM1_BIP_CNTR_A3		85
+#define RMIO_PWM1_BIP_CNTR_A4		86
+#define RMIO_PWM1_BIP_CNTR_A5		87
+#define RMIO_PWM1_BIP_CNTR_B0		88
+#define RMIO_PWM1_BIP_CNTR_B1		89
+#define RMIO_PWM1_BIP_CNTR_B2		90
+#define RMIO_PWM1_BIP_CNTR_B3		91
+#define RMIO_PWM1_BIP_CNTR_B4		92
+#define RMIO_PWM1_BIP_CNTR_B5		93
+#define RMIO_PDM_CLK1			94
+#define RMIO_ETH_RMII0_PPSCLK		95
+#define RMIO_ETH_RMII0_PPSTRIG		96
+#define RMIO_ETH_RMII1_PPSCLK		97
+#define RMIO_ETH_RMII1_PPSTRIG		98
+
+#endif /* __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H */
-- 
2.34.1

Hi Ye,

thanks for your patch!

On Tue, Dec 16, 2025 at 3:50 PM Ye Zhang <ye.zhang@rock-chips.com> wrote:


> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml

> +  rockchip,rmio-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      The phandle of the syscon node (GRF or PMU) containing the RMIO registers.
> +      This property is required if the RMIO registers are located in a different
> +      syscon than the parent pinctrl node.
> +
> +  rockchip,offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The offset of the RMIO configuration registers within the GRF.

Can't this just be a cell in the phandle?

> +  rockchip,pins-num:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of physical pins supported by this RMIO instance.
> +      Used for boundary checking and driver initialization.

Isn't this implicit from the compatible? Why is this different
between two device trees using the same compatible pin
controller? I don't get it, I think this should be a constant in the
code based on the compatible instead.

> +patternProperties:
> +  "^[a-z0-9-]+$":
> +    type: object
> +    description:
> +      Function node grouping multiple groups.
> +
> +    patternProperties:
> +      "^[a-z0-9-]+$":
> +        type: object
> +        description:
> +          Group node containing the pinmux configuration.
> +
> +        properties:
> +          rockchip,rmio:
> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +            description:
> +              A list of pin-function pairs. The format is <pin_id function_id>.
> +            minItems: 1
> +            items:
> +              items:
> +                - description: RMIO Pin ID (0 to pins-num - 1)
> +                  minimum: 0
> +                  maximum: 31
> +                - description: Function ID
> +                  minimum: 0
> +                  maximum: 98

Please avoid these custom properties and just use the standard
"pinmux" property. I don't want any more opaque custom bindings
for functions and groups.

Reference Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
and use pinmux from there.

You can use some shifting and defines to shoehorn your config
into a single u32 and parse that in your driver; i.e. instead of
rockchip,rmio = <1, 2>;
use
pinmux = <1 << 8 | 2 << 0>;
these shifter numerals can come from defines.
In the driver shift & mask out the components you want.

e.g.;

> +            rmio-uart {
> +                rmio_pin27_uart1_tx: rmio-pin27-uart1-tx {
> +                    rockchip,rmio = <27 RMIO_UART1_TX>;

pinmux = <27 << 8 | RMIO_UART1_TX>;

> +++ b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h

These number dumps are not appreciated inside the bindings
despite quite a few found their way in there.

Use something like
arch/*/dts/rockchip/rk3506-rmio-pins.dtsi
and include that into your device trees instead.

Yours,
Linus Walleij

Correcting myself:

On Fri, Dec 26, 2025 at 7:07 PM Linus Walleij <linusw@kernel.org> wrote:

> > +  rockchip,offset:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      The offset of the RMIO configuration registers within the GRF.
>
> Can't this just be a cell in the phandle?

This can probably also be determined from the comaptible, can it not?

Yours,
Linus Walleij

在 2025/12/27 2:07, Linus Walleij 写道:
> Hi Ye,
>
> thanks for your patch!
>
> On Tue, Dec 16, 2025 at 3:50 PM Ye Zhang <ye.zhang@rock-chips.com> wrote:
>
>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>> +  rockchip,rmio-grf:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      The phandle of the syscon node (GRF or PMU) containing the RMIO registers.
>> +      This property is required if the RMIO registers are located in a different
>> +      syscon than the parent pinctrl node.
>> +
>> +  rockchip,offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      The offset of the RMIO configuration registers within the GRF.
> Can't this just be a cell in the phandle?
In my upcoming v4, it will be moved into the driver code.
>> +  rockchip,pins-num:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      The number of physical pins supported by this RMIO instance.
>> +      Used for boundary checking and driver initialization.
> Isn't this implicit from the compatible? Why is this different
> between two device trees using the same compatible pin
> controller? I don't get it, I think this should be a constant in the
> code based on the compatible instead.
In my upcoming v4, it will be moved into the driver code.
>> +patternProperties:
>> +  "^[a-z0-9-]+$":
>> +    type: object
>> +    description:
>> +      Function node grouping multiple groups.
>> +
>> +    patternProperties:
>> +      "^[a-z0-9-]+$":
>> +        type: object
>> +        description:
>> +          Group node containing the pinmux configuration.
>> +
>> +        properties:
>> +          rockchip,rmio:
>> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> +            description:
>> +              A list of pin-function pairs. The format is <pin_id function_id>.
>> +            minItems: 1
>> +            items:
>> +              items:
>> +                - description: RMIO Pin ID (0 to pins-num - 1)
>> +                  minimum: 0
>> +                  maximum: 31
>> +                - description: Function ID
>> +                  minimum: 0
>> +                  maximum: 98
> Please avoid these custom properties and just use the standard
> "pinmux" property. I don't want any more opaque custom bindings
> for functions and groups.
>
> Reference Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
> and use pinmux from there.
>
> You can use some shifting and defines to shoehorn your config
> into a single u32 and parse that in your driver; i.e. instead of
> rockchip,rmio = <1, 2>;
> use
> pinmux = <1 << 8 | 2 << 0>;
> these shifter numerals can come from defines.
> In the driver shift & mask out the components you want.
>
> e.g.;
>
>> +            rmio-uart {
>> +                rmio_pin27_uart1_tx: rmio-pin27-uart1-tx {
>> +                    rockchip,rmio = <27 RMIO_UART1_TX>;
> pinmux = <27 << 8 | RMIO_UART1_TX>;

In v4, I will remove rockchip,rmio.yaml

I understand your preference for standard bindings.  However, there is a 
specific constraint here: the RMIO acts as a secondary layer of muxing, 
sitting behind the primary IOMUX controller.

The existing Rockchip pinctrl binding uses the vendor-specific 
rockchip,pins property for the primary IOMUX configuration.  If I were 
to use the standard pinmux property for RMIO, the node would contain 
mixed bindings like this:

node {
     /* Primary IOMUX (existing binding) */
     rockchip,pins = <1 RK_PB1 16 &pcfg_pull_none>;
     /* Secondary RMIO  */
     pinmux = <(RMIO_ID << 16) | (RMIO_PIN << 8) | RMIO_FUNC>;
};

Since this node describes a single hardware pin configuration that 
requires two separate hardware settings (Primary Mux + Secondary RMIO), 
I thought keeping the secondary config as a vendor-specific property 
(rockchip,rmio) alongside rockchip,pins would be more consistent and 
less confusing than mixing legacy custom bindings with standard pinmux.

In v4, I have removed the separate RMIO child node entirely.  The RMIO 
configuration is now integrated into the main pinctrl group as a 
supplemental property:

node {

rockchip,pins = <1 RK_PB1 7 &pcfg_pull_none>

/* rmio_id pin_id func_id */
rockchip,rmio-pins = <0 24 68>;
};

>
>> +++ b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
> These number dumps are not appreciated inside the bindings
> despite quite a few found their way in there.
>
> Use something like
> arch/*/dts/rockchip/rk3506-rmio-pins.dtsi
> and include that into your device trees instead.
In my upcoming v4, rockchip,rk3506-rmio.h will be removed.

On Sat, Dec 27, 2025 at 3:46 AM Ye Zhang <ye.zhang@rock-chips.com> wrote:

> I understand your preference for standard bindings.  However, there is a
> specific constraint here: the RMIO acts as a secondary layer of muxing,
> sitting behind the primary IOMUX controller.
>
> The existing Rockchip pinctrl binding uses the vendor-specific
> rockchip,pins property for the primary IOMUX configuration.  If I were
> to use the standard pinmux property for RMIO, the node would contain
> mixed bindings like this:
>
> node {
>      /* Primary IOMUX (existing binding) */
>      rockchip,pins = <1 RK_PB1 16 &pcfg_pull_none>;
>      /* Secondary RMIO  */
>      pinmux = <(RMIO_ID << 16) | (RMIO_PIN << 8) | RMIO_FUNC>;
> };
>
> Since this node describes a single hardware pin configuration that
> requires two separate hardware settings (Primary Mux + Secondary RMIO),
> I thought keeping the secondary config as a vendor-specific property
> (rockchip,rmio) alongside rockchip,pins would be more consistent and
> less confusing than mixing legacy custom bindings with standard pinmux.

I see the concern but I would say two wrongs doesn't make one right.

The DT binding people will have to say what to do here, but ideally
I would say the primary IOMUX should be modified to *also* *additionally*
support the standard bindings and deprecating the old rockchip,pins,
and then you can consistently use the pinmux=<>; binding in new
trees for both pinmuxes.

I understand that maybe you are only working on this other controller
and might feel that the primary IOMUX is none of your concern,
but someone has to stand up and take the responsibility for the system
as a whole, if no-one else then the Rockchip SoC maintainer, else
we get throw-over-the-wall-engineering.

Yours,
Linus Walleij

在 2026/1/4 19:44, Linus Walleij 写道:
> On Sat, Dec 27, 2025 at 3:46 AM Ye Zhang <ye.zhang@rock-chips.com> wrote:
>
>> I understand your preference for standard bindings.  However, there is a
>> specific constraint here: the RMIO acts as a secondary layer of muxing,
>> sitting behind the primary IOMUX controller.
>>
>> The existing Rockchip pinctrl binding uses the vendor-specific
>> rockchip,pins property for the primary IOMUX configuration.  If I were
>> to use the standard pinmux property for RMIO, the node would contain
>> mixed bindings like this:
>>
>> node {
>>       /* Primary IOMUX (existing binding) */
>>       rockchip,pins = <1 RK_PB1 16 &pcfg_pull_none>;
>>       /* Secondary RMIO  */
>>       pinmux = <(RMIO_ID << 16) | (RMIO_PIN << 8) | RMIO_FUNC>;
>> };
>>
>> Since this node describes a single hardware pin configuration that
>> requires two separate hardware settings (Primary Mux + Secondary RMIO),
>> I thought keeping the secondary config as a vendor-specific property
>> (rockchip,rmio) alongside rockchip,pins would be more consistent and
>> less confusing than mixing legacy custom bindings with standard pinmux.
> I see the concern but I would say two wrongs doesn't make one right.
>
> The DT binding people will have to say what to do here, but ideally
> I would say the primary IOMUX should be modified to *also* *additionally*
> support the standard bindings and deprecating the old rockchip,pins,
> and then you can consistently use the pinmux=<>; binding in new
> trees for both pinmuxes.
>
> I understand that maybe you are only working on this other controller
> and might feel that the primary IOMUX is none of your concern,
> but someone has to stand up and take the responsibility for the system
> as a whole, if no-one else then the Rockchip SoC maintainer, else
> we get throw-over-the-wall-engineering.
Hi Linus,

We have discussed this internally, and we fully agree with your suggestion:
the driver should be modified to *additionally* support the standard
bindings, allowing us to eventually deprecate the old `rockchip,pins`.

**Regarding the RMIO support in this series:**
I am willing to implement the standard `pinmux` binding for the
**RMIO** part immediately in this v5. This ensures that the new feature
starts with the correct, standard binding.

**Regarding the primary IOMUX:**
However, the RK3506 pinctrl support is built upon the existing
`pinctrl-rockchip` driver infrastructure, which was originally designed 
around
the `rockchip,pins` property. Refactoring the driver to support the standard
`pinmux` binding (and the suggested nested node structure) is a significant
undertaking that involves core logic changes and regression risks for older
SoCs. Mandating this refactoring as a prerequisite for RK3506 support
would effectively block this SoC from being supported upstream for a 
long time.

Could we allow RK3506 to follow the existing driver's style for now to 
ensure
consistency and timely support? We agree that migrating to standard pinmux
bindings is the right direction, but we believe it should be handled as a
separate, dedicated project in the future rather than part of this 
enablement series.

Hi Heiko,
Do you agree with this?
1.        Use standard `pinmux` for RMIO in this series.
2.        Keep `rockchip,pins` for the primary IOMUX for now.
3.        Plan a future refactoring to migrate the primary IOMUX to 
standard bindings.

Best regards,
Ye Zhang

Hi Ye,

thanks for agreeing on using standard bindings for
RMIO, we are making progress!

On Thu, Jan 8, 2026 at 1:19 PM Ye Zhang <ye.zhang@rock-chips.com> wrote:

> **Regarding the primary IOMUX:**
> However, the RK3506 pinctrl support is built upon the existing
> `pinctrl-rockchip` driver infrastructure, which was originally designed
> around
> the `rockchip,pins` property. Refactoring the driver to support the standard
> `pinmux` binding (and the suggested nested node structure) is a significant
> undertaking that involves core logic changes and regression risks for older
> SoCs. Mandating this refactoring as a prerequisite for RK3506 support
> would effectively block this SoC from being supported upstream for a
> long time.
>
> Could we allow RK3506 to follow the existing driver's style for now to
> ensure
> consistency and timely support?

"timely support" is of lesser concern to the kernel and DT
bindings which are more concerned with maintainability and long-term
longevity. The ambition is to work predictably and impersonal, such
as like the planets, or the plants.

> We agree that migrating to standard pinmux
> bindings is the right direction, but we believe it should be handled as a
> separate, dedicated project in the future rather than part of this
> enablement series.
>
> Hi Heiko,
> Do you agree with this?
> 1.        Use standard `pinmux` for RMIO in this series.
> 2.        Keep `rockchip,pins` for the primary IOMUX for now.
> 3.        Plan a future refactoring to migrate the primary IOMUX to
> standard bindings.

My main concern is this:

foo {
    rockchip,pins = <...>; // For IOMUX
    pinmux = <...>; /// for RMIO
};

I don't want to see this, because that will be *hopeless* to migrate
to both controllers using pinmux = <...>; how should you decide
which one to pick for each?

In that case it is better to do:

foo {
    rockchip,pins = <...>;
    rmio {
        pinmux = <....>;
    };
};

Because then you can later migrate to:

foo {
    iomux {
        pinmux = <....>;
    };
    rmio {
        pinmux = <...>;
    };
};

Yours,
Linus Walleij

On 16/12/2025 12:20, Ye Zhang wrote:
> 1. Add header file with constants for RMIO function IDs for the Rockchip
> RK3506 SoC.
> 2. Add device tree binding for the RMIO (Rockchip Matrix I/O) controller
> which is a sub-device of the main pinctrl on some Rockchip SoCs.
> 
> Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com>
> ---
>  .../bindings/pinctrl/rockchip,pinctrl.yaml    |   9 ++
>  .../bindings/pinctrl/rockchip,rmio.yaml       | 106 +++++++++++++++++
>  .../pinctrl/rockchip,rk3506-rmio.h            | 109 ++++++++++++++++++
>  3 files changed, 224 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>  create mode 100644 include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> index 97960245676d..9a27eaf7942b 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> @@ -82,6 +82,15 @@ required:
>    - rockchip,grf
>  
>  patternProperties:
> +  "rmio[0-9]*$":
> +    type: object
> +
> +    $ref: "/schemas/pinctrl/rockchip,rmio.yaml#"
> +
> +    description:
> +      The RMIO (Rockchip Matrix I/O) controller node which functions as a
> +      sub-device of the main pinctrl to handle flexible function routing.

No. Your child has no resources, so it's not proper hardware
representation. Don't use Linux driver model in the bindings.

That's a NAK. Don't send the same AGAIN without addressing comments like
you did here.

> +
>    "gpio@[0-9a-f]+$":
>      type: object
>  
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
> new file mode 100644
> index 000000000000..af0b34512fb9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
> @@ -0,0 +1,106 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/rockchip,rmio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RMIO (Rockchip Matrix I/O) Controller
> +
> +maintainers:
> +  - Heiko Stuebner <heiko@sntech.de>
> +
> +description: |
> +  The RMIO controller provides a flexible routing matrix that allows mapping
> +  various internal peripheral functions (UART, SPI, PWM, etc.) to specific
> +  physical pins. This block is typically a sub-block of the GRF
> +  (General Register Files) or PMU (Power Management Unit).
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - rockchip,rk3506-rmio
> +      - const: rockchip,rmio

I don't see how pinctrl deserves generic compatible. I already commented
on this.


> +
> +  rockchip,rmio-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      The phandle of the syscon node (GRF or PMU) containing the RMIO registers.
> +      This property is required if the RMIO registers are located in a different
> +      syscon than the parent pinctrl node.

Why "if"? How this can be flexible?

Anyway, you did not address my previous comment at all.

NAK

> +
> +  rockchip,offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The offset of the RMIO configuration registers within the GRF.

No, this belongs to the phandle.

Look how this is already described and do not come with other style.

> +
> +  rockchip,pins-num:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of physical pins supported by this RMIO instance.
> +      Used for boundary checking and driver initialization.
> +
> +patternProperties:
> +  "^[a-z0-9-]+$":

No, use a prefix or suffix. See other pinctrl bindings.

> +    type: object
> +    description:
> +      Function node grouping multiple groups.
> +
> +    patternProperties:
> +      "^[a-z0-9-]+$":

Same ocmment

> +        type: object
> +        description:
> +          Group node containing the pinmux configuration.
> +
> +        properties:
> +          rockchip,rmio:
> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +            description:
> +              A list of pin-function pairs. The format is <pin_id function_id>.
> +            minItems: 1
> +            items:
> +              items:
> +                - description: RMIO Pin ID (0 to pins-num - 1)
> +                  minimum: 0
> +                  maximum: 31
> +                - description: Function ID
> +                  minimum: 0
> +                  maximum: 98
> +
> +        required:
> +          - rockchip,rmio

Why aren't you using standard pinctrl bindings?

> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - rockchip,rmio-grf
> +  - rockchip,offset
> +  - rockchip,pins-num
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/pinctrl/rockchip,rk3506-rmio.h>
> +
> +    pinctrl: pinctrl {

What's this?

> +        rmio: rmio {
> +            compatible = "rockchip,rk3506-rmio", "rockchip,rmio";
> +            rockchip,rmio-grf = <&grf_pmu>;
> +            rockchip,offset = <0x80>;
> +            rockchip,pins-num = <32>;
> +
> +            rmio-uart {
> +                rmio_pin27_uart1_tx: rmio-pin27-uart1-tx {
> +                    rockchip,rmio = <27 RMIO_UART1_TX>;
> +                };
> +
> +                rmio_pin28_uart1_rx: rmio-pin28-uart1-rx {
> +                    rockchip,rmio = <28 RMIO_UART1_RX>;
> +                };
> +            };
> +        };
> +    };
> diff --git a/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
> new file mode 100644
> index 000000000000..b129e9a8c287
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
> @@ -0,0 +1,109 @@
> +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
> +/*
> + * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
> +#define __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
> +
> +/* RMIO function definition */
> +#define RMIO_UART1_TX			1
> +#define RMIO_UART1_RX			2
> +#define RMIO_UART2_TX			3
> +#define RMIO_UART2_RX			4
> +#define RMIO_UART3_TX			5
> +#define RMIO_UART3_RX			6
> +#define RMIO_UART3_CTSN			7
> +#define RMIO_UART3_RTSN			8
> +#define RMIO_UART4_TX			9
> +#define RMIO_UART4_RX			10
> +#define RMIO_UART4_CTSN			11
> +#define RMIO_UART4_RTSN			12
> +#define RMIO_MIPITE			13
> +#define RMIO_CLK_32K			14
> +#define RMIO_I2C0_SCL			15
> +#define RMIO_I2C0_SDA			16


I do not see how this is a binding. Please point me to the patch using
this in the driver.

Best regards,
Krzysztof

在 2025/12/16 23:52, Krzysztof Kozlowski 写道:
> On 16/12/2025 12:20, Ye Zhang wrote:
>> 1. Add header file with constants for RMIO function IDs for the Rockchip
>> RK3506 SoC.
>> 2. Add device tree binding for the RMIO (Rockchip Matrix I/O) controller
>> which is a sub-device of the main pinctrl on some Rockchip SoCs.
>>
>> Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com>
>> ---
>>   .../bindings/pinctrl/rockchip,pinctrl.yaml    |   9 ++
>>   .../bindings/pinctrl/rockchip,rmio.yaml       | 106 +++++++++++++++++
>>   .../pinctrl/rockchip,rk3506-rmio.h            | 109 ++++++++++++++++++
>>   3 files changed, 224 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>>   create mode 100644 include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
>> index 97960245676d..9a27eaf7942b 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
>> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
>> @@ -82,6 +82,15 @@ required:
>>     - rockchip,grf
>>   
>>   patternProperties:
>> +  "rmio[0-9]*$":
>> +    type: object
>> +
>> +    $ref: "/schemas/pinctrl/rockchip,rmio.yaml#"
>> +
>> +    description:
>> +      The RMIO (Rockchip Matrix I/O) controller node which functions as a
>> +      sub-device of the main pinctrl to handle flexible function routing.
> No. Your child has no resources, so it's not proper hardware
> representation. Don't use Linux driver model in the bindings.
>
> That's a NAK. Don't send the same AGAIN without addressing comments like
> you did here.
I understand your point now.  In v4, I will remove rockchip,rmio. yaml 
and drop the separate RMIO child node entirely.
Instead of creating a fake device node, I will use a phandle property 
within the main pinctrl node to reference the GRF/PMU syscon that 
contains the RMIO registers.  For example:
rockchip,rmio-grf = <&rmio_grf>;
The fixed parameters (like offset and pin count) will be moved into the 
driver code.
>> +
>>     "gpio@[0-9a-f]+$":
>>       type: object
>>   
>> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>> new file mode 100644
>> index 000000000000..af0b34512fb9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>> @@ -0,0 +1,106 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pinctrl/rockchip,rmio.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: RMIO (Rockchip Matrix I/O) Controller
>> +
>> +maintainers:
>> +  - Heiko Stuebner <heiko@sntech.de>
>> +
>> +description: |
>> +  The RMIO controller provides a flexible routing matrix that allows mapping
>> +  various internal peripheral functions (UART, SPI, PWM, etc.) to specific
>> +  physical pins. This block is typically a sub-block of the GRF
>> +  (General Register Files) or PMU (Power Management Unit).
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - rockchip,rk3506-rmio
>> +      - const: rockchip,rmio
> I don't see how pinctrl deserves generic compatible. I already commented
> on this.
In v4, I will remove the generic compatible string rockchip,rmio and 
rely solely on the specific compatible.  Since the separate RMIO node is 
being removed (as per the point above), this compatible issue will 
naturally be resolved as the logic moves into the main driver.
>
>> +
>> +  rockchip,rmio-grf:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      The phandle of the syscon node (GRF or PMU) containing the RMIO registers.
>> +      This property is required if the RMIO registers are located in a different
>> +      syscon than the parent pinctrl node.
> Why "if"? How this can be flexible?
>
> Anyway, you did not address my previous comment at all.
>
> NAK
The description will be corrected to"Phandles to the GRF/PMU syscons 
containing the RMIO registers. These are required to access the RMIO 
controller registers"

>> +
>> +  rockchip,offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      The offset of the RMIO configuration registers within the GRF.
> No, this belongs to the phandle.
>
> Look how this is already described and do not come with other style.
In v4, I will remove rockchip,rmio. yaml

>> +
>> +  rockchip,pins-num:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      The number of physical pins supported by this RMIO instance.
>> +      Used for boundary checking and driver initialization.
>> +
>> +patternProperties:
>> +  "^[a-z0-9-]+$":
> No, use a prefix or suffix. See other pinctrl bindings.
In v4, I will remove rockchip,rmio. yaml

>> +    type: object
>> +    description:
>> +      Function node grouping multiple groups.
>> +
>> +    patternProperties:
>> +      "^[a-z0-9-]+$":
> Same ocmment
>
>> +        type: object
>> +        description:
>> +          Group node containing the pinmux configuration.
>> +
>> +        properties:
>> +          rockchip,rmio:
>> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> +            description:
>> +              A list of pin-function pairs. The format is <pin_id function_id>.
>> +            minItems: 1
>> +            items:
>> +              items:
>> +                - description: RMIO Pin ID (0 to pins-num - 1)
>> +                  minimum: 0
>> +                  maximum: 31
>> +                - description: Function ID
>> +                  minimum: 0
>> +                  maximum: 98
>> +
>> +        required:
>> +          - rockchip,rmio
> Why aren't you using standard pinctrl bindings?
The standard pinmux binding is not suitable here because RMIO acts as a 
secondary layer of muxing, distinct from the primary IOMUX.
The primary IOMUX (handled by rockchip,pins) routes the pin to the RMIO 
block, while the RMIO configuration determines the specific function 
within that block.
In v4, I plan to define rockchip,rmio as a supplemental vendor-specific 
property within the pin group, formatted as <rmio_id rmio_pin_id 
rmio_function>.

For example:

&pinctrl {
         rm_io24 {
                 /omit-if-no-ref/
                 rm_io24_uart1_tx: rm-io24-uart1-tx {
                         rockchip,pins =
                                 <1 RK_PB1 16 &pcfg_pull_none>;
                         rockchip,rmio =
                                 <0 24 RMIO_UART1_TX>;
                 };
};

>> +
>> +        additionalProperties: false
>> +
>> +    additionalProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - rockchip,rmio-grf
>> +  - rockchip,offset
>> +  - rockchip,pins-num
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/pinctrl/rockchip,rk3506-rmio.h>
>> +
>> +    pinctrl: pinctrl {
> What's this?
In v4, I will remove rockchip,rmio. yaml
>> +        rmio: rmio {
>> +            compatible = "rockchip,rk3506-rmio", "rockchip,rmio";
>> +            rockchip,rmio-grf = <&grf_pmu>;
>> +            rockchip,offset = <0x80>;
>> +            rockchip,pins-num = <32>;
>> +
>> +            rmio-uart {
>> +                rmio_pin27_uart1_tx: rmio-pin27-uart1-tx {
>> +                    rockchip,rmio = <27 RMIO_UART1_TX>;
>> +                };
>> +
>> +                rmio_pin28_uart1_rx: rmio-pin28-uart1-rx {
>> +                    rockchip,rmio = <28 RMIO_UART1_RX>;
>> +                };
>> +            };
>> +        };
>> +    };
>> diff --git a/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
>> new file mode 100644
>> index 000000000000..b129e9a8c287
>> --- /dev/null
>> +++ b/include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
>> @@ -0,0 +1,109 @@
>> +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
>> +/*
>> + * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
>> +#define __DT_BINDINGS_PINCTRL_ROCKCHIP_RK3506_RMIO_H
>> +
>> +/* RMIO function definition */
>> +#define RMIO_UART1_TX			1
>> +#define RMIO_UART1_RX			2
>> +#define RMIO_UART2_TX			3
>> +#define RMIO_UART2_RX			4
>> +#define RMIO_UART3_TX			5
>> +#define RMIO_UART3_RX			6
>> +#define RMIO_UART3_CTSN			7
>> +#define RMIO_UART3_RTSN			8
>> +#define RMIO_UART4_TX			9
>> +#define RMIO_UART4_RX			10
>> +#define RMIO_UART4_CTSN			11
>> +#define RMIO_UART4_RTSN			12
>> +#define RMIO_MIPITE			13
>> +#define RMIO_CLK_32K			14
>> +#define RMIO_I2C0_SCL			15
>> +#define RMIO_I2C0_SDA			16
>
> I do not see how this is a binding. Please point me to the patch using
> this in the driver.
These macros are intended to be used in the Device Tree sources to 
improve readability, avoiding “magic numbers” for the RMIO function IDs.

For example, instead of writing <0 24 1>, the DTS uses <0 24 
RMIO_UART1_TX>, which is much clearer.

in v4, I will provide the relevant dts
> Best regards,
> Krzysztof
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>

On Tue, 16 Dec 2025 19:20:52 +0800, Ye Zhang wrote:
> 1. Add header file with constants for RMIO function IDs for the Rockchip
> RK3506 SoC.
> 2. Add device tree binding for the RMIO (Rockchip Matrix I/O) controller
> which is a sub-device of the main pinctrl on some Rockchip SoCs.
> 
> Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com>
> ---
>  .../bindings/pinctrl/rockchip,pinctrl.yaml    |   9 ++
>  .../bindings/pinctrl/rockchip,rmio.yaml       | 106 +++++++++++++++++
>  .../pinctrl/rockchip,rk3506-rmio.h            | 109 ++++++++++++++++++
>  3 files changed, 224 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/rockchip,rmio.yaml
>  create mode 100644 include/dt-bindings/pinctrl/rockchip,rk3506-rmio.h
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml:88:11: [error] string value is redundantly quoted with any quotes (quoted-strings)

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pinctrl/rockchip,rmio.example.dtb: rmio (rockchip,rk3506-rmio): compatible: ['rockchip,rk3506-rmio', 'rockchip,rmio'] is not of type 'object'
	from schema $id: http://devicetree.org/schemas/pinctrl/rockchip,rmio.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20251216112053.1927852-7-ye.zhang@rock-chips.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.