From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: robh@kernel.org, krzk+dt@kernel.org
Cc: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Shenwei Wang <shenwei.wang@nxp.com>, Peng Fan <peng.fan@nxp.com>,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-imx@nxp.com,
Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>,
b-padhi@ti.com, Andrew Lunn <andrew@lunn.ch>,
viresh.kumar@linaro.org
Subject: Re: [PATCH v15 2/5] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
Date: Thu, 3 Sep 2026 11:30:04 -0600 [thread overview]
Message-ID: <apmunD8bkKOu5_Vm@p14s> (raw)
In-Reply-To: <20260721204704.400781-3-shenwei.wang@oss.nxp.com>
Krzysztof and Rob - I'm seeking your advice on the best way to define bindings
for this use case.
Here is some background:
The transport mechanic between the kernel and remote processors can take
different forms. As of this writing we have 'glink' and 'virtio'. The protocol
that runs on top of the transport mechanic is RPMSG. All this is already
implemented and stable.
In this use case, we have GPIO controllers connected to the remote processor and
we want to make them available to the kernel. We also want to use the existing
virtio-gpio protocol on top of RPMSG, allowing the kernel to interface with the
GPIO controllers as if they were virtio-gpios. This patchset is about providing
a driver that will enact the virtio-gpio procotol on top of the mechanic used
between the kernel and remote processor.
Shenwei has proposed some bindings (below). I think they can be improved to
take into account the transport mechanic and be closer to what virtio-gpio
currently does. I'm proposing something like this:
$(transport) {
compatible = "$(transport),rpmsg";
#address-cells = <1>;
#size-cells = <0>;
gpio {
compatible = "virtio,device29";
reg = <3>
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio {
compatible = "virtio,device29";
reg = <4>
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
}
A complete example with a virtio transport mechanic would look like:
m4_rproc: m4@10000000 {
compatible = "st,stm32mp1-m4";
reg = <0x10000000 0x40000>,
<0x30000000 0x40000>,
<0x38000000 0x10000>;
resets = <&rcc MCU_R>;
reset-names = "mcu_rst";
st,syscfg-holdboot = <&rcc 0x10C 0x1>;
st,syscfg-pdds = <&pwr_mcu 0x0 0x1>;
st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
status = "disabled";
virtio {
compatible = "virtio,rpmsg";
#address-cells = <1>;
#size-cells = <0>;
gpio {
compatible = "virtio,device29";
reg = <3>
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio {
compatible = "virtio,device29";
reg = <4>
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
}
};
};
Let me know what you think.
Thanks,
Mathieu
On Tue, Jul 21, 2026 at 03:46:45PM -0500, Shenwei Wang wrote:
> From: Shenwei Wang <shenwei.wang@nxp.com>
>
> Remote processors may announce multiple GPIO controllers over an RPMSG
> channel. These GPIO controllers may require corresponding device tree
> nodes, especially when acting as providers, to supply phandles for their
> consumers.
>
> Define an RPMSG node to work as a container for a group of RPMSG channels
> under the imx_rproc node. Each subnode within "rpmsg" represents an
> individual RPMSG channel. The name of each subnode corresponds to the
> channel name as defined by the remote processor.
>
> All remote devices associated with a given channel are defined as child
> nodes under the corresponding channel node.
>
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
> .../devicetree/bindings/gpio/gpio-rpmsg.yaml | 55 +++++++++++++++++++
> .../bindings/remoteproc/fsl,imx-rproc.yaml | 53 ++++++++++++++++++
> 2 files changed, 108 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> new file mode 100644
> index 000000000000..41eb2e149942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-rpmsg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic RPMSG GPIO Controller
> +
> +maintainers:
> + - Shenwei Wang <shenwei.wang@nxp.com>
> +
> +description:
> + On an AMP platform, some GPIO controllers are exposed by the remote processor
> + through the RPMSG bus. The RPMSG GPIO transport protocol defines the packet
> + structure and communication flow between Linux and the remote firmware. Those
> + controllers are managed via this transport protocol. For more details of the
> + protocol, check the document below.
> + Documentation/driver-api/gpio/gpio-rpmsg.rst
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,rpmsg-gpio
> + - const: rpmsg-gpio
> + - const: rpmsg-gpio
> +
> + reg:
> + description:
> + The reg property represents the index of the GPIO controllers. Since
> + the driver manages controllers on a remote system, this index tells
> + the remote system which controller to operate.
> + maxItems: 1
> +
> + "#gpio-cells":
> + const: 2
> +
> + gpio-controller: true
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - "#gpio-cells"
> + - gpio-controller
> +
> +allOf:
> + - $ref: /schemas/gpio/gpio.yaml#
> +
> +unevaluatedProperties: false
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..b9b559b186af 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -88,6 +88,34 @@ properties:
> This property is to specify the resource id of the remote processor in SoC
> which supports SCFW
>
> + rpmsg:
> + type: object
> + additionalProperties: false
> + description:
> + Represents the RPMSG bus between Linux and the remote system. Contains
> + a group of RPMSG channel devices running on the bus.
> +
> + properties:
> + rpmsg-io:
> + type: object
> + additionalProperties: false
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^gpio@[0-9a-f]+$":
> + type: object
> + $ref: /schemas/gpio/gpio-rpmsg.yaml#
> + unevaluatedProperties: false
> +
> + required:
> + - '#address-cells'
> + - '#size-cells'
> +
> required:
> - compatible
>
> @@ -150,5 +178,30 @@ examples:
> &mu 3 1>;
> memory-region = <&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
> syscon = <&src>;
> +
> + rpmsg {
> + rpmsg-io {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@0 {
> + compatible = "rpmsg-gpio";
> + reg = <0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + };
> +
> + gpio@1 {
> + compatible = "rpmsg-gpio";
> + reg = <1>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + };
> + };
> + };
> };
> ...
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-09-03 17:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 20:46 [PATCH v15 0/5] Enable Remote GPIO over RPMSG on i.MX Platform Shenwei Wang
2026-07-21 20:46 ` [PATCH v15 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus Shenwei Wang
2026-07-21 20:46 ` [PATCH v15 2/5] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support Shenwei Wang
2026-08-24 14:38 ` Mathieu Poirier
2026-08-26 18:36 ` Shenwei Wang (OSS)
2026-08-27 15:36 ` Mathieu Poirier
2026-09-03 17:30 ` Mathieu Poirier [this message]
2026-09-03 20:05 ` Shenwei Wang (OSS)
2026-09-04 5:43 ` Viresh Kumar
2026-07-21 20:46 ` [PATCH v15 3/5] rpmsg: core: match rpmsg device IDs by prefix Shenwei Wang
2026-07-21 20:46 ` [PATCH v15 4/5] gpio: rpmsg: add generic rpmsg GPIO driver Shenwei Wang
2026-07-23 6:33 ` Uwe Kleine-König
2026-07-21 20:46 ` [PATCH v15 5/5] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc Shenwei Wang
2026-07-31 17:11 ` [PATCH v15 0/5] Enable Remote GPIO over RPMSG on i.MX Platform Mathieu Poirier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apmunD8bkKOu5_Vm@p14s \
--to=mathieu.poirier@linaro.org \
--cc=Frank.Li@nxp.com \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--cc=arnaud.pouliquen@foss.st.com \
--cc=b-padhi@ti.com \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shenwei.wang@nxp.com \
--cc=skhan@linuxfoundation.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox