[PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus

Shenwei Wang shenwei.wang at nxp.com
Mon Nov 10 08:30:29 PST 2025



> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Monday, November 10, 2025 9:59 AM
> 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>;
> Jonathan Corbet <corbet at lwn.net>; 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; linux-
> doc at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>
> Subject: [EXT] Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus
> > The remote firmware does not need to know whether Linux is asleep. The
> > GPIO is not used to wake Linux directly; instead, it serves as a
> > wake-up source for the remote firmware if configured accordingly. Once
> > the remote firmware is awake, it sends a notification message to Linux. This
> notification is the actual event that wakes Linux.
> >
> > This works because there is always a physical interface connecting Linux and
> the remote firmware.
> > On i.MX platforms, this interface is the MU block. When the remoteproc
> > driver is running, the MU block is automatically configured as a
> > wake-up source for Linux by default. As a result, the notification message can
> wake the Linux system if it is asleep.
> 
> You need to add a lot more documentation to the specification to make this
> clear. As you said, the firmware and Linux have different sleep/wake life cycles.
> How does the firmware know it is safe to go to sleep, if it has no idea Linux is
> running or suspended?
> 

The remoteproc driver is responsible for managing the remote firmware. The GPIO driver 
operates independently of this process and functions transparently on top of it. 
So the GPIO driver does not require to know the firmware's running states.

Thanks,
Shenwei

>         Andrew



More information about the linux-arm-kernel mailing list