Should we utilize official IPC frameowrk instead reinverting the wheel? 1.Load firmware by drivers/remoteproc https://www.kernel.org/doc/Documentation/remoteproc.txt 2.Do the comunication through drivers/rpmsg https://www.kernel.org/doc/Documentation/rpmsg.txt Many vendor(TI, Qualcomm, ST, NXP, Xilinx...) migrate to remoteproc/rpmsg, why Intel provide an other IPC mechanism? Actually, remoteproc/rpmsg is much better than SOF IPC because: 1.Completely isolate the firmware load and message transfer: The same rpmsg driver could run on any remote processor 2.Separate the application protocol from transfer layer: One remote processor could host many rpmsg services 3.Completely follow kernel driver model(rpsmg_bus, rpmsg_device and rpmsg_driver). 4.Support by many RTOS(Bare Metal, FreeRTOS, Zephyr, NuttX, Nucleus, uC/OS...) for remote side: https://github.com/OpenAMP/open-amp https://github.com/NXPmicro/rpmsg-lite 5.Maintained by the standard committee: https://www.multicore-association.org/workgroup/oamp.php https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio Since the keypoint of SOF is the platform agnostic and modular, please use the standard technique here. Thanks Xiang _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
