[alsa-devel] [Sound-open-firmware] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core

[Pierre-Louis Bossart]

On 2/22/19 2:32 AM, xiang xiao wrote:
> On Thu, Feb 21, 2019 at 11:27 PM Pierre-Louis Bossart
> <pierre-louis.bossart at linux.intel.com> 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.
>>
>> Rather than evolve the IPC, i would say it makes more sense that we
>> "reuse" existing upstream frameworks.. As given below by xiang
>> this seems to have support for RTOSes (see point 4 below) and looking at
>> below it seems to have much better coverage across systems.
>>
>> This should also help in easy adoption of SoF for non Intel people...
>>
>> Also looking at it, lot of IPC code, DSP loading etc would go away
>> making SoF code lesser in footprint.
>>
>> I think benefits outweigh the effort of porting to a framework which is
>> already upstream and used on many platforms for different vendors!
>>
>> There is no free lunch. There are 'features' of RPMsg which aren't necessarily great for all platforms, e.g. the concepts of virtio-like rings for IPC with available/used buffers for both directions are not a good match or replacement for the memory-window-based IPC on Intel platforms, where there is no DDR access, a small window allocated by firmware and only a couple of doorbell registers for essentially serial communication.
> rpmsg support to define the custom mechanism(see rpmsg_endpoint_ops in
> drivers\rpmsg\rpmsg_internal.h) but keep the upper layer API, qcomm
> utilize this for glink and smd actually.

That's interesting. Can anyone at Qualcomm/Linaro point to actual 
examples of the implementation, so that we get a better picture of the 
split between 'upper layer API' and 'custom mechanism'?

>
>> The resources embedded in a firmware file is another capability that doesn't align with the way the SOF firmware is generated. I also don't know where the topology file would be handled, nor how to deal with suspend-resume where the DSP needs to be restarted. For folks who need an introduction to RPMsg, the link [1] is the best I found to scope out the work required.
>>
> We can share our rpmsg based topology implementation as reference which:
> 1.About 2500 lines(much less than SOF)
> 2.Support pcm and compress playback/capture
> 3.No any vendor dependence(thanks for rpmsg/remoteproc)

Sure. Where's the code? What's the license?

Most of the SOF code is really in hardware-specific .ops callbacks and 
topology handling, the generic IPC layer is only ~800 lines of code. 
rpmsg would allow for easier portability but a significant reduction of 
the code size is unlikely.