> -----Original Message-----
> From: Andrew Lunn <[email protected]>
> Sent: Saturday, November 8, 2025 11:46 AM
> To: Shenwei Wang <[email protected]>
> Cc: Bjorn Andersson <[email protected]>; Mathieu Poirier
> <[email protected]>; Rob Herring <[email protected]>; Krzysztof
> Kozlowski <[email protected]>; Conor Dooley <[email protected]>; Shawn
> Guo <[email protected]>; Sascha Hauer <[email protected]>;
> Jonathan Corbet <[email protected]>; Linus Walleij <[email protected]>;
> Bartosz Golaszewski <[email protected]>; Pengutronix Kernel Team
> <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan
> <[email protected]>; [email protected];
> [email protected]; [email protected]; linux-arm-
> [email protected]; [email protected]; linux-
> [email protected]; dl-linux-imx <[email protected]>
> 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
