[PATCH v3 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Thursday, October 9, 2025 5:59 PM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; Rob Herring <robh at kernel.org>; Krzysztof
> Kozlowski <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Shawn
> Guo <shawnguo at kernel.org>; Sascha Hauer <s.hauer at pengutronix.de>; Linus
> Walleij <linus.walleij at linaro.org>; Bartosz Golaszewski <brgl at bgdev.pl>;
> Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>; linux-
> remoteproc at vger.kernel.org; devicetree at vger.kernel.org; imx at lists.linux.dev;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; dl-linux-imx
> <linux-imx at nxp.com>
> Subject: [EXT] Re: [PATCH v3 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver
> On Thu, Oct 09, 2025 at 05:27:15PM -0500, Shenwei Wang wrote:
> > On i.MX SoCs, the system may include two processors:
> >       - An MCU running an RTOS
> >       - An MPU running Linux
> >
> > These processors communicate via the RPMSG protocol.
> > The driver implements the standard GPIO interface, allowing the Linux
> > side to control GPIO controllers which reside in the remote processor
> > via RPMSG protocol.
> 
> I've not seen the discussion on earlier versions of this patchset, so i might be
> asking something already asked and answered. Sorry if i am.
> 
> Is there anything IMX specific in here? This appears to be the first RPMSG GPIO
> driver. Do we have the opportunity here to define a protocol for all future RPMSG
> GPIO drivers, which any/all vendors should follow, so we don't have lots of
> different implementations of basically they same thing? So this would become
> gpio-rpmsg.c and a Document somewhere describing the protocol?
> 

The only platform-specific part is the message format exchanged between Linux and the remote processors.
As long as the remote processor follows the same message protocol, the driver should work as expected.

Here's the layout of the message packets:

+--------+--------+--------+--------+--------+----------------+--------+--------+---------------+---------------+
|0x00    |0x01    |0x02    |0x03    |0x04    |0x05..0x09      |0x0A    |0x0B    |0x0C           |0x0D           |
|cate    |major   |minor   |type    |cmd     |reserved[5]     |pin_idx |port_idx|out:{evt/rc/v} |in:{wkup/val}  |
+--------+--------+--------+--------+--------+----------------+--------+--------+---------------+---------------+

Cate (Category field ): can be GPIO /I2C/PMIC/AUDIO ... etc
Major : Major version number
Minor: Minor version number
Type (Message Type): Can be SETUP / REPLY /NOTIFY for GPIO category
Cmd (Command): Can be Input INIT / Output INIT / Input GET for GPIO category
Pin_idx: The GPIO line index
Port_idx: The GPIO controller index

For Out packet:  
	if it is OUPUT INIT, the out field value is the gpio output level.
	If it is INPUT INIT, the out filed is 0.

For In packet:
	If it is a REPLY message, the out field is return code. 0 means success.  
	If it is a REPLY of INPUT GET, the in field is the value of GPIO line level.
	If it is an NOTIFY type of message, it simulates an interrupt event from the remote processor.

I can add above comments in the commit log or the beginning of the driver source file.

Thanks,
Shenwei

>         Andrew