On 18/02/2019 20:03, Xiang Xiao wrote:
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?
It definitely makes more sense to use rpmsg for Generic IPC driver here.
Qualcomm DSP audio drivers (non SOF) already use rpmsg. This will
definitely help everyone in future while immigrating to SOF.
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
--srini
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
