Phil-Engljaehringer opened a new pull request, #21114: URL: https://github.com/apache/nuttx/pull/21114
drivers/rptun: Add optional kick_host operation, implement it for imx9. *Note: Please adhere to [Contributing Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).* ## Summary In the remote role, rptun has no way to tell the host that it has (re)started and is waiting for the virtio devices to be set up. The existing ops either notify a vring (`notify`) or go from the master to the remote (`reset`, `panic`). This matters when the host keeps running while the remote cpu reboots, e.g. Linux in remoteproc attach mode on i.MX95 while the M7 is reset or reflashed. The M7 comes back with a fresh resource table and waits for `DRIVER_OK`, but Linux does not notice the restart and never attaches again. The M7 stays in `rptun_create_devices()` until the host is detached/attached manually. This PR adds the signal in two commits: 1. **drivers/rptun: Add optional kick_host operation.** Adds `kick_host` to `struct rptun_ops_s` and the `RPTUN_KICK_HOST()` macro (no-op if the op is not set, same pattern as `RPTUN_PANIC()`/`RPTUN_RESET()`). `rptun_start_thread()` calls it in the remote role right after `rptun_do_start()`, i.e. right before it starts polling for `DRIVER_OK`. It runs on every start (autostart, `RPTUNIOC_START`, `rptun_boot()`). 2. **arch/arm/src/imx9: rptun: Kick the host via MU general purpose interrupt 1.** Implements the op by setting GCR.GIR1 on the M7 side of the MU, which raises GIP1 on the host side. In the Linux `imx_rproc` driver this is the `rxdb` mailbox channel. The doorbell is opt-in with the new Kconfig option `IMX9_RPTUN_KICK_HOST` (default n). Host side: mainline / linux-imx `imx_rproc` does not act on the `rxdb` doorbell yet. We use an out-of-tree `imx_rproc` patch that detaches and attaches again when the doorbell arrives and the vdev status in the shared resource table is not `DRIVER_OK` (the latter filters out stale doorbells). A host that does not listen to the doorbell ignores it. ## Impact * Is new feature added? YES: optional rptun op `kick_host`, imx9 implementation behind `CONFIG_IMX9_RPTUN_KICK_HOST`. * Is existing feature changed? NO. The op is optional; drivers that do not set it are not affected. imx9 only sets it when the new option is enabled (default n). * Impact on user (will user need to adapt to change)? NO. * Impact on build (will build process change)? NO. One new Kconfig option, default n. * Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO for existing configurations. With the option enabled, i.MX95 M7 and i.MX93 M33 (both use `imx9_rptun.c`) ring MU GIR1 once per rptun start. * Impact on documentation (is update required / provided)? NO. The option is described in its Kconfig help. * Impact on security (any sort of implications)? NO. * Impact on compatibility (backward/forward/interoperability)? NO. A new member is appended at the end of `struct rptun_ops_s`; designated initializers in all in-tree drivers leave it NULL. * Anything else to consider or add? The host-side receiver is out of tree (see Summary). ## Testing Build host: Linux 6.17 x86_64, AMD Ryzen AI 9 HX 370, arm-none-eabi-gcc 14.2.1 20241119. Target: NXP i.MX95 M7 on mr-navq95b (`mr-navq95b:rpmsg` + `CONFIG_IMX9_RPTUN_KICK_HOST=y`), Linux on the A55 in remoteproc attach mode with the `imx_rproc` rxdb patch. Checks: * `./tools/checkpatch.sh -f` on all changed files and `./tools/checkpatch.sh -c -u -m -g HEAD~2..HEAD`: pass. * Build `mr-navq95b:rpmsg` with the option off and on: TODO <rc / warnings>. Runtime test: reset only the M7 while Linux keeps running and check whether Linux attaches again. TODO: ADD TEST RESULTS HERE ## AI assistance and sign-off The change was prepared with the help of an AI assistant (Claude Code), as stated in the `Assisted-by` trailers. I reviewed, built and tested it and take responsibility for it; the commits carry my `Signed-off-by`. -- 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]
