IPM deprecation schedule and transition to MBOX

[iuliana-prodan]

During the recent OpenAMP technical meeting, several questions came up regarding the long-term status of the IPM (Inter-Processor Mailbox) API in Zephyr. In particular, we were unsure whether some of the existing Zephyr samples should be migrated from the IPM API to the MBOX API. This led to a broader conversation about the overall direction of IPM support.

In addition, there are new samples that developers would like to upstream into mainline Zephyr, but these samples still rely on the IPM API - see #97117.
If IPM is indeed on a path toward deprecation, it may make more sense for such samples to be submitted directly with MBOX support rather than adding more IPM-based content.

Currently, it appears that the deprecation of IPM is not documented anywhere in the official Zephyr documentation (I've checked https://docs.zephyrproject.org/latest/hardware/peripherals/ipm.html or https://docs.zephyrproject.org/latest/doxygen/html/group__ipm__interface.html#details)
If IPM is intended to be deprecated, adding an explicit note or section in the docs could help users and contributors understand the plan and avoid confusion.

To move forward constructively, we might consider outlining a structured deprecation strategy such as:

1. do not accept any new IPM drivers (this is already mostly the practice, with guidance to implement MBOX instead)
2. do not accept new samples using the IPM API; encourage the use of the MBOX or IPC APIs for new contributions
3. begin porting existing IPM drivers to MBOX, where applicable
4. start migrating existing samples from the IPM API to the MBOX API, reducing long-term maintenance burden

As a side note, Zephyr already includes an IPM-over-MBOX driver (drivers/ipm/ipm_mbox.c), which may help ease the transition for users with legacy dependencies.

Maybe I should create a tracking issue, similar to this one:
#64477 - to document the plan, gather feedback, and monitor ongoing deprecation progress?

Request for comments / feedback

1. Do you agree that an IPM deprecation plan is needed?
2. When would be a reasonable timeframe to start this transition?
3. Do you see value in updating documentation to clarify the intended future of the IPM API?
4. Are there any objections or concerns about not accepting new IPM drivers or samples going forward?

Any questions, concerns, or alternative suggestions are very welcome.
We’d appreciate input on whether this direction makes sense and how you would like to proceed with defining the schedule.

cc: @arnopo @glneo

[iuliana-prodan]

@nashif @carlescufi @dcpleung @kartben please let me know what you think, and feel free to add anyone who might be interested in this discussion.

[dcpleung]

The ipm_box driver does not exactly implement all IPM functionality. For example, the id and wait arguments in ipm_send() are not used. Moreover, device tree still needs to be modified for ipm_box to work. So it is not a drop-in replacement. Therefore, I recommend deprecating the whole IPM block at the same time. Maybe targeting some time after next LTS?

[carlescufi]

@dcpleung wouldn't it be better to deprecate IPM and port the current in-tree IPM drivers at the same time, and do that right now?

[dcpleung]

Oh... what I meant by "some time after next LTS" was about removal (... I wasn't cleared on that). We can definitely start the deprecation process now and start to move everyone off IPM.