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

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Saturday, November 8, 2025 11:46 AM
> To: Shenwei Wang <shenwei.wang@xxxxxxx>
> Cc: Bjorn Andersson <andersson@xxxxxxxxxx>; Mathieu Poirier
> <mathieu.poirier@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof
> Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Shawn
> Guo <shawnguo@xxxxxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>;
> Jonathan Corbet <corbet@xxxxxxx>; Linus Walleij <linus.walleij@xxxxxxxxxx>;
> Bartosz Golaszewski <brgl@xxxxxxxx>; Pengutronix Kernel Team
> <kernel@xxxxxxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxxxx>; Peng Fan
> <peng.fan@xxxxxxx>; linux-remoteproc@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> doc@xxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>
> 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