Phil-Engljaehringer opened a new pull request, #20890:
URL: https://github.com/apache/nuttx/pull/20890
## Summary
Add support for SCMI platform-to-agent (P2A) notifications from the
i.MX95 System Manager (SM) and for LMM events of other logical machines.
Use case: the M7 needs to know when the Linux LM (LM2) reboots, e.g. to
restart its remoteproc/RPMsg link.
New API in `imx9_scmi.h`:
- `imx9_scmi_notify_register(cb, arg)`: installs a single callback for
all SCMI notifications. A second registration returns `-EBUSY`.
- `imx9_scmi_lmmnotify(channel, lmid, flags)`: subscribes to boot/shutdown
(and suspend/wake) events of a logical machine (`LMM_NOTIFY`, msg 0x9).
- `imx9_scmi_lmmevent(&lmid, &eventlm, &flags)`: reads an `LMM_EVENT`
(msg 0x0) from inside the callback.
- `SCMI_PROTOCOL_*` IDs move from `imx9_scmi.c` to the header so callbacks
can dispatch on them; `SCMI_MSG_LMM_EVENT` and `SCMI_LMM_EVENT_*` are new.
How it works:
- The SM writes a notification into the notify SMT channel and rings MU5
general purpose interrupt 1.
- The MU5 GPI handler passes protocol and message ID to the callback in
interrupt context. The callback reads the payload with a protocol
specific function (for now `imx9_scmi_lmmevent()`, which checks the CRC
and the header) and must defer anything that blocks.
- After the callback returns, the handler marks the channel free and rings
the doorbell back, so the SM can send the next queued notification (the
boot event follows the shutdown event shortly after).
The callback runs in interrupt context, like the MU message callback that
`imx9_rptun.c` already uses, instead of being deferred to a work queue as
Linux does. The SM sends the next notification only after the channel is
handed back, so acking right after a short callback frees it immediately,
while a worker would hold the channel until it runs. It also avoids a
dependency on `CONFIG_SCHED_WORKQUEUE`, which most imx9 defconfigs don't
enable. Callbacks that need to block (e.g. call SCMI request functions)
defer that work themselves.
Two details needed to make this work:
1. The MU5 IRQ is attached and enabled in `imx9_scmi_notify_register()`,
not in `imx9_scmi_initialize()`. The latter runs from `__start()` before
`irq_initialize()` and `up_irqinitialize()`, which reset the vector
table and NVIC, so an IRQ set up there is lost. Polled SCMI calls are
not affected.
2. The notify channel is marked free on registration, because the SM only
sends notifications to a free channel.
Example board usage (callback in interrupt context, board decides what to
do with the event):
```c
static void board_scmi_notify(uint32_t protocol, uint32_t msgid, void *arg)
{
uint32_t lm;
uint32_t flags;
if (protocol != SCMI_PROTOCOL_LMM || msgid != SCMI_MSG_LMM_EVENT ||
imx9_scmi_lmmevent(NULL, &lm, &flags) != OK)
{
return;
}
if (flags & SCMI_LMM_EVENT_SHUTDOWN)
{
syslog(LOG_WARNING, "SCMI: LM%" PRIu32 " shut down\n", lm);
}
if (flags & SCMI_LMM_EVENT_BOOT)
{
syslog(LOG_INFO, "SCMI: LM%" PRIu32 " booted\n", lm);
}
}
imx9_scmi_notify_register(board_scmi_notify, NULL);
imx9_scmi_lmmnotify(SM_PLATFORM_A2P, 2,
SCMI_LMM_EVENT_BOOT | SCMI_LMM_EVENT_SHUTDOWN);
```
Requires #20875 (merged) at runtime: before it, MU general purpose
interrupts were only handled together with RFP, so the doorbell was never
serviced.
## Impact
- Is new feature added? YES: new arch API `imx9_scmi_notify_register()`,
`imx9_scmi_lmmnotify()`, `imx9_scmi_lmmevent()`. Nothing changes until
board code calls it.
- Impact on user: NO.
- Impact on build: NO. No new Kconfig options or dependencies.
- Impact on hardware: i.MX95 (Cortex-M7, `arch/arm/src/imx9`) only.
- Impact on documentation: NO.
- Impact on security: NO.
- Impact on compatibility: NO. Existing SCMI calls are unchanged; the
`SCMI_PROTOCOL_*` defines only moved to the header.
## Testing
Build host: Linux 6.17 x86_64, AMD Ryzen AI 9 HX 370,
arm-none-eabi-gcc 14.2.1 20241119.
Build tests on current master, no warnings:
- `mr-navq95b:rpmsg`
- `mr-navq95b:nsh`
The new functions are compiled into `imx9_scmi.o` (no in-tree caller yet,
so they are dropped at link time).
Runtime test on hardware (NavQ95 / mr-navq95b, M7 = LM1, Linux = LM2),
using a NuttX 12.12 based tree with the identical change (only the
`imx95_mu_*` names of that version differ). The board code registers a
callback like the example above and subscribes to LM2 boot/shutdown
events. The SM configuration grants the M7 agent `NOTIFY` access to LM2.
Then `sudo reboot` on Linux.
Before (no notification support): nothing on the M7 console, the M7 can't
tell that Linux rebooted.
After (M7 console):
```
SCMI: LM2 shut down
SCMI: LM2 booted
```
The M7 keeps running, both events arrive in order, and repeated Linux
reboots give the same output. In that test setup the shutdown callback
also triggered an RPMsg restart, and the link to Linux came back after
the reboot (the rptun part is not in this PR).
## Self-Check
- [x] Commit message follows CONTRIBUTING.md
- [x] `./tools/checkpatch.sh -f` passes on both files, `-c -u -m -g` passes
- [x] Builds without warnings
## AI assistance and sign-off
The port to master and the commit message were prepared with the help of
an AI assistant (noted with an `Assisted-by` trailer). I reviewed the
change, ran the hardware tests myself and signed off the commit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
