On 2/19/19 9:09 AM, xiang xiao wrote:
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
The IPC scheme suggested in this patchset is only a first pass that
works on 3 generations on Intel platforms + the QEMU parts. There are
no claims that the current solution is set-in-stone, and this is already
an area where things are already changing to support notifications and
low-power transitions.
There will clearly be evolutions to make the IPC more flexible/generic,
but we've got to start somewhere and bear in mind that we also have to
support memory-constrained legacy devices where such generic frameworks
aren't needed or even implementable. Some of your proposals such as
changing power/clocks with a firmware request aren't necessarily
possible or recommended on all platforms - i can already hear security
folks howling, this was already mentioned in the GitHub thread.
There are other paths such as using the mailbox framework, and at the
end of the day the IPC is likely going to be a configurable element
where integrators pick what's best for them. If you strongly believe
that the RPMSG framework is the way to go, there is a public github and
you can contribute the relevant changes with both kernel and firmware
patches.
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.
As stated above there is no opposition to using fancier/more generic IPC
solutions, but they have to be considered as evolutions and follow the
due process of contributions/reviews plus be aligned with product timelines.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
