On Tue, Feb 19, 2019 at 5:49 PM Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote: > > > > 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, Xiaomi also build DSP audio driver on top of rpmsg, but fully integrate with the ASoC topology framework, and the firmware is base on FreeRTOS and OpenMAX. SOF initiative is very good and exciting, our team members(include me) spend a couple weeks to study the current code base on both firmware and kernel side, we even port SOF to our DSP/MCU and make it run, but I have to point out that: SOF IPC is too simple and rigid, tightly couple with Intel platform and audio domain, which make: a.It's difficult to integrate with other vendor SoC, especially if other vendor already adopt remote/rpmsg(this is already a trend!). b.It's difficult to add other IPC services for example: i.Audio DSP talk to power MCU to adjust clock and voltage ii.Export ultrasonic distance measurement to IIO subsystem > > 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
