Message-ID:
 <PAXPR04MB9185156672C7B334E717F11789CEA@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date: Mon, 10 Nov 2025 15:24:37 +0000
From: Shenwei Wang <shenwei.wang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Bjorn Andersson <andersson@...nel.org>, Mathieu Poirier
	<mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Shawn Guo
	<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Jonathan Corbet
	<corbet@....net>, Linus Walleij <linus.walleij@...aro.org>, Bartosz
 Golaszewski <brgl@...ev.pl>, Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, Peng Fan <peng.fan@....com>,
	"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Saturday, November 8, 2025 11:46 AM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: Bjorn Andersson <andersson@...nel.org>; Mathieu Poirier
> <mathieu.poirier@...aro.org>; Rob Herring <robh@...nel.org>; Krzysztof
> Kozlowski <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Shawn
> Guo <shawnguo@...nel.org>; Sascha Hauer <s.hauer@...gutronix.de>;
> Jonathan Corbet <corbet@....net>; Linus Walleij <linus.walleij@...aro.org>;
> Bartosz Golaszewski <brgl@...ev.pl>; Pengutronix Kernel Team
> <kernel@...gutronix.de>; Fabio Estevam <festevam@...il.com>; Peng Fan
> <peng.fan@....com>; linux-remoteproc@...r.kernel.org;
> devicetree@...r.kernel.org; imx@...ts.linux.dev; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-
> doc@...r.kernel.org; dl-linux-imx <linux-imx@....com>
> Subject: [EXT] Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus
> > The remote system should always aim to stay in a power-efficient state
> > by shutting down or clock-gating any blocks that aren't in use. In
> > this wakeup scenario, if no GPIO lines are requested or marked as
> > wakeup sources for Linux, the remote firmware should put the GPIO controller
> into a low-power state.
> 
> There are no messages defined to tell the GPIO controller Linux is suspended.
> 
> Since the firmware has no idea Linux is asleep, the firmware is performing all the
> usual processing, driving output pins, monitoring input pins, delivering interrupt
> notifications. If no pins are marked as wakeup, it can then enter some sort of
> low-power state, which allows it to do all this work, plus save power? How?
> 
> I've also been thinking about what a wake up source actually means. I've been
> looking at this from one use case i know, an Ethernet PHY performing Wake on
> LAN? What normally happens is that Linux suspends, but leaves the main SoC
> interrupt controller enabled, and parts of the GPIO controller. The GPIO controller
> has a hard wired connection to the interrupt controller. When the PHY indicated
> WoL by driving its output pin low, triggering an interrupt, the GPIO triggers the
> main interrupt controller, which wakes the CPU.
> 
> How does this work here, in a message passing system? Linux is asleep. While
> asleep, does it still process all remote proc messages?
> How? Does it wake up for each message and go back to sleep once it finds it is a
> non wake notification? Since the firmware does not know Linux is asleep, it will
> still be sending notifications for non-wake interrupts. How does Linux actually
> know to wake up? Do you require that the low level remote proc mechanism is
> also wake capable? So in effect, Linux needs to go up the device chain and enable
> wake source not only in the GPIO layer but also the remote proc layer? And
> whatever mechanism that is based on, until you get to an interrupt which can
> actually wake the system?
> 

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.

Thanks,
Shenwei

> > Okay. To fully simulate a level-triggered interrupt, a notification reply message
> is required.
> 
> I would not word it like that. All you currently have is edge. To simulate level
> triggered interrupts you need a notification reply message.
> 
> > Remote firmware sequence:
> > Receive the level-triggered GPIO interrupt.
> > Mask the interrupt for the corresponding line.
> > Send a notification message to Linux.
> > Wait for the notification reply, then unmask the interrupt for the line.
> >
> > Linux sequence:
> > Receive the notification message.
> > Invoke the interrupt handler for the line.
> > Send a notification reply to the remote firmware to indicate End of Interrupt
> (EOI).
> 
> That sounds more reasonable.
> 
>         Andrew

Powered by blists - more mailing lists