Phil-Engljaehringer opened a new pull request, #20875:
URL: https://github.com/apache/nuttx/pull/20875
arch/arm/src/imx9: Handle MU general purpose interrupts without RFP.
## Summary
* **Why:** `imx9_mu_interrupt()` only checks the GSR general purpose
interrupt pending bits inside the `SR.RFP` (receive full pending) branch. A
general purpose interrupt that is not accompanied by a receive register write
is therefore never acknowledged nor passed to the subscribed callback. This is
the case for SCMI P2A notification doorbells from the i.MX95 System Manager,
which only set `GCR.GIRn` (`RPC_SMT_DoorbellRing()` -> `MB_MU_DoorbellRing()`
-> `MU_TriggerInterrupts()`) and never write a transmit register. The pending
bit stays set while it is enabled in `GIER`, so the MU interrupt fires again
immediately and the core is stuck in the handler (interrupt storm).
* **What:** `arch/arm/src/imx9/imx9_mu.c`, `imx9_mu_interrupt()`.
* **How:** GSR is now checked on every MU interrupt, independent of
`SR.RFP`, masked with `GIER` so only subscribed general purpose interrupts are
acknowledged and reported. The receive register path is unchanged.
* The commit also fixes the existing nxstyle errors in the same file
(indentation of the MU7/MU8 checks in `imx9_mu_init()`, braces for the
busy-wait loop in `imx9_mu_send_msg()`), no functional change there.
## Impact
* Is new feature added? Is existing feature changed? NO. Bug fix of the
existing general purpose interrupt handling.
* Impact on user (will user need to adapt to change)? NO.
* Impact on build (will build process change)? NO.
* Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES,
i.MX9 Cortex-M MU driver (`arch/arm/src/imx9/imx9_mu.c`). Only users of
`imx9_mu_subscribe_gpi()` see a behavioral difference; there is no in-tree user
yet. It is needed for upcoming SCMI LMM (logical machine) boot/shutdown
notification support on the i.MX95 M7. RPMsg over MU7 (receive registers only,
no GPI subscription) is unaffected.
* Impact on documentation (is update required / provided)? NO.
* Impact on security (any sort of implications)? NO.
* Impact on compatibility (backward/forward/interoperability)? NO.
* Anything else to consider or add? `arch/arm64/src/imx9/imx9_mu.c` has
the same structure and very likely the same issue; it is not changed here.
## Testing
I confirm that changes are verified on local setup and work as intended:
* Build Host: Linux 6.17 x86_64 (AMD Ryzen AI 9 HX 370),
`arm-none-eabi-gcc 14.2.1 20241119`.
* Target: NXP NavQ95 (i.MX95), NuttX on the Cortex-M7, Linux on the
Cortex-A55. The M7 subscribes to SCMI LMM notifications for the A55 logical
machine on MU5 doorbell 1.
* Runtime tested on hardware with a NuttX 12.12 based tree containing the
identical change. On current master the commit was build tested
(`mr-navq95b:rpmsg`, no warnings).
* Style checks: `./tools/checkpatch.sh -c -u -m -g HEAD~1..HEAD` and
`./tools/checkpatch.sh -f arch/arm/src/imx9/imx9_mu.c` pass.
* Steps to reproduce: subscribe to SCMI LMM notifications on MU5 doorbell
1 on the M7, then reboot Linux on the A55. The System Manager sends an LMM
event to the M7.
Testing logs before change (Linux on the A55 rebooted, GDB attached to the
M7). Every halt lands in the MU5 interrupt handler, entered directly from the
exception path on top of an idle thread:
```
(gdb) bt
#0 imx9_mu_interrupt (irq=221, context=0x0, args=0x20000024 <g_mu5_dev>)
at chip/imx9_mu.c:98
#1 0x90102ed4 in exception_direct () at armv7-m/arm_doirq.c:51
#2 <signal handler called>
#3 0x90106568 in nxsem_wait_slow (sem=0x20026a0c) at
semaphore/sem_wait.c:284
#4 0x0000125c in nxsem_wait (sem=<optimized out>) at
semaphore/sem_wait.c:201
#5 0x90103cc2 in sem_wait (sem=<optimized out>) at semaphore/sem_wait.c:92
#6 0x9027a882 in px4::WorkQueue::Run (...)
...
(gdb) c
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
imx9_mu_interrupt (irq=221, context=0x0, args=0x20000024 <g_mu5_dev>) at
chip/imx9_mu.c:97
(gdb) c
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
imx9_mu_interrupt (irq=221, context=0x0, args=0x20000024 <g_mu5_dev>) at
chip/imx9_mu.c:97
(gdb) c
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
imx9_mu_interrupt (irq=<optimized out>, context=<optimized out>,
args=0x20000024 <g_mu5_dev>) at chip/imx9_mu.c:134
```
Testing logs after change (same setup, Linux rebooted, M7 console). The
notifications are received and the M7 keeps running; repeated Linux reboots
work:
```
SCMI: LM2 shut down
SCMI: LM2 booted
```
## AI assistance and sign-off
* This change was developed with assistance from Claude Opus 5.5 (GitHub
Copilot). The commit carries `Assisted-by: GitHub-Copilot:claude-opus-5.5` as
required by the Contributing Guide (section 1.5).
* The commit is signed off by the author: `Signed-off-by:
Phil-Engljaehringer <[email protected]>`.
## PR verification Self-Check
* [x] This PR introduces only one functional change.
* [x] I have updated all required description fields above.
* [x] My PR adheres to Contributing
[Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md) and
[Documentation](https://nuttx.apache.org/docs/latest/contributing/index.html)
(git commit title and message, coding standard, etc).
* [ ] My PR is still work in progress (not ready for review).
* [x] My PR is ready for review and can be safely merged into a codebase.
--
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]
