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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2019/2/23 上午2:21, xiang xiao wrote:
On Fri, Feb 22, 2019 at 7:13 PM Keyon Jie <yang.jie@xxxxxxxxxxxxxxx> wrote:
Then this looks doable, thanks for sharing Xiang.

I have several questions:
1. Is virtio device and vring buffer access support in remote proc(Audio
DSP in our case) side mandatory? Which means we have to porting
libraries like libAMP into FW(not uses Zephyr or freeRTOS yet)?

If you go through viritio/rpmsg path, virtio/vring are required,
but if you implement the new rpmsg_endpoint_ops, both shouldn't be needed.
But both OpenAMP/RPMsg-Lite support the bare metal environment,
actually since both library define the clean and thin port layer, it's
very easy to port(I just spend 2-3 days for NuttX port).

Thanks for sharing, that's good if it is possible to go without virtio support at the first step, we will do investigation based on code you shared.


2. About the resource table in FW binary, is this mandatory or it could
be empty?

Again virtio/rpmsg path is required, but custom implementation mayn't needed.
Actually, remoteproc layer support the custom firmware format, so SOF
can migrate to remoteproc without changing firmware format.

Good to know this, thanks.

Thanks,
~Keyon



As you may know, we uses SOF-similar IPC framework(which is quite
different with rpmsg/remoteproc) on Intel SoC platforms for long on tens
of platforms of several generations(we have enabled and verified SOF on
most of them), so the transition may take time.


Yes, I understand. But Intel still could provide the current version
to the customer before the new IPC version is stable if many people
think the generic IPC is the good direction to go.

Thanks,
~Keyon


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.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux