All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keyon Jie <yang.jie@linux.intel.com>
To: xiang xiao <xiaoxiang781216@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>,
	Kumar Gala <kumar.gala@linaro.org>,
	andriy.shevchenko@intel.com, alsa-devel@alsa-project.org,
	tiwai@suse.de, linux-remoteproc@vger.kernel.org,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	liam.r.girdwood@linux.intel.com, Vinod Koul <vkoul@kernel.org>,
	broonie@kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Xiang Xiao <xiaoxiang@xiaomi.com>,
	sound-open-firmware@alsa-project.org, wendy.liang@xilinx.com,
	Alan Cox <alan@linux.intel.com>
Subject: Re: [Sound-open-firmware] [alsa-devel] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core
Date: Mon, 25 Feb 2019 11:05:15 +0800	[thread overview]
Message-ID: <22872b53-338f-df35-8682-129b2db83b7e@linux.intel.com> (raw)
In-Reply-To: <CAH2Cfb-efq1U_r5jgvef-PQDg3+oZg2TofLXh=S03pyaqjVcPQ@mail.gmail.com>



On 2019/2/23 上午2:21, xiang xiao wrote:
> On Fri, Feb 22, 2019 at 7:13 PM Keyon Jie <yang.jie@linux.intel.com> 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.
>>>>

WARNING: multiple messages have this Message-ID (diff)
From: Keyon Jie <yang.jie@linux.intel.com>
To: xiang xiao <xiaoxiang781216@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>,
	Kumar Gala <kumar.gala@linaro.org>,
	andriy.shevchenko@intel.com, Alan Cox <alan@linux.intel.com>,
	tiwai@suse.de, Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	linux-remoteproc@vger.kernel.org, alsa-devel@alsa-project.org,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	liam.r.girdwood@linux.intel.com, Vinod Koul <vkoul@kernel.org>,
	broonie@kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Xiang Xiao <xiaoxiang@xiaomi.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	wendy.liang@xilinx.com, sound-open-firmware@alsa-project.org
Subject: Re: [Sound-open-firmware]  [v4, 00/14] ASoC: Sound Open Firmware (SOF) core
Date: Mon, 25 Feb 2019 11:05:15 +0800	[thread overview]
Message-ID: <22872b53-338f-df35-8682-129b2db83b7e@linux.intel.com> (raw)
In-Reply-To: <CAH2Cfb-efq1U_r5jgvef-PQDg3+oZg2TofLXh=S03pyaqjVcPQ@mail.gmail.com>



On 2019/2/23 上午2:21, xiang xiao wrote:
> On Fri, Feb 22, 2019 at 7:13 PM Keyon Jie <yang.jie@linux.intel.com> 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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-02-25  3:03 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 22:07 [PATCH v4 00/14] ASoC: Sound Open Firmware (SOF) core Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 01/14] ASoC: SOF: Add Sound Open Firmware driver core Pierre-Louis Bossart
2019-02-14  9:25   ` Takashi Iwai
2019-02-14 14:53     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-19 15:38       ` Mark Brown
2019-02-20 14:35         ` Pierre-Louis Bossart
2019-02-20 16:26           ` Mark Brown
2019-02-20 21:32             ` Pierre-Louis Bossart
2019-02-21 18:47               ` Mark Brown
2019-02-22  0:08                 ` Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 02/14] ASoC: SOF: Add Sound Open Firmware KControl support Pierre-Louis Bossart
2019-02-14  9:30   ` Takashi Iwai
2019-02-14 14:35     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-14 15:21       ` Takashi Iwai
2019-02-13 22:07 ` [PATCH v4 03/14] ASoC: SOF: Add driver debug support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 04/14] ASoC: SOF: Add support for IPC IO between DSP and Host Pierre-Louis Bossart
2019-02-14 11:52   ` Takashi Iwai
2019-02-14 14:56     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-20 17:31       ` Mark Brown
2019-02-13 22:07 ` [PATCH v4 05/14] ASoC: SOF: Add PCM operations support Pierre-Louis Bossart
2019-02-14 11:20   ` Takashi Iwai
2019-02-14 15:07     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-14 20:42       ` Pierre-Louis Bossart
2019-02-18 15:51   ` Daniel Baluta
2019-02-13 22:07 ` [PATCH v4 06/14] ASoC: SOF: Add support for loading topologies Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 07/14] ASoC: SOF: Add DSP firmware logger support Pierre-Louis Bossart
2019-02-14 13:19   ` Takashi Iwai
2019-02-14 15:13     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-20 17:44   ` Mark Brown
2019-02-20 20:18     ` Pierre-Louis Bossart
2019-02-21 12:29       ` Andy Shevchenko
2019-02-21 14:57         ` Pierre-Louis Bossart
2019-02-21 15:04         ` Mark Brown
2019-02-13 22:07 ` [PATCH v4 08/14] ASoC: SOF: Add DSP HW abstraction operations Pierre-Louis Bossart
2019-02-14 13:21   ` Takashi Iwai
2019-02-14 15:22     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-14 13:45   ` Andy Shevchenko
2019-02-14 15:21     ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 09/14] ASoC: SOF: Add firmware loader support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 10/14] ASoC: SOF: Add userspace ABI support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 11/14] ASoC: SOF: Add PM support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 12/14] ASoC: SOF: Add Nocodec machine driver support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 13/14] ASoC: SOF: Add xtensa support Pierre-Louis Bossart
2019-02-13 22:07 ` [PATCH v4 14/14] ASoC: SOF: Add utils Pierre-Louis Bossart
2019-02-14 13:33   ` Takashi Iwai
2019-02-14 13:37     ` Takashi Iwai
2019-02-18 20:03 ` [v4,00/14] ASoC: Sound Open Firmware (SOF) core Xiang Xiao
2019-02-19  9:49   ` [alsa-devel] " Srinivas Kandagatla
2019-02-19  9:49     ` Srinivas Kandagatla
2019-02-19 15:09     ` [alsa-devel] " xiang xiao
2019-02-19 15:09       ` xiang xiao
2019-02-19 15:55       ` [alsa-devel] " Pierre-Louis Bossart
2019-02-19 15:55         ` Pierre-Louis Bossart
2019-02-21  4:39         ` [alsa-devel] " Vinod Koul
2019-02-21  4:39           ` Vinod Koul
2019-02-21 10:42           ` [alsa-devel] " Arnaud Pouliquen
2019-02-21 10:42             ` Arnaud Pouliquen
2019-02-21 11:28             ` [alsa-devel] " Mark Brown
2019-02-21 11:28               ` Mark Brown
2019-02-21 23:49               ` [alsa-devel] " Pierre-Louis Bossart
2019-02-21 23:49                 ` Pierre-Louis Bossart
2019-02-21 15:27           ` [alsa-devel] " Pierre-Louis Bossart
2019-02-21 15:27             ` Pierre-Louis Bossart
2019-02-22  8:32             ` [alsa-devel] " xiang xiao
2019-02-22  8:32               ` xiang xiao
2019-02-22 11:15               ` [alsa-devel] " Keyon Jie
2019-02-22 11:15                 ` Keyon Jie
2019-02-22 18:21                 ` [alsa-devel] " xiang xiao
2019-02-22 18:21                   ` xiang xiao
2019-02-25  3:05                   ` Keyon Jie [this message]
2019-02-25  3:05                     ` [Sound-open-firmware] [v4, 00/14] " Keyon Jie
2019-02-22 14:48               ` [Sound-open-firmware] [alsa-devel] " Pierre-Louis Bossart
2019-02-22 14:48                 ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-02-22 18:41                 ` [Sound-open-firmware] [alsa-devel] " xiang xiao
2019-02-22 18:41                   ` [Sound-open-firmware] " xiang xiao
2019-02-22 21:52                   ` [alsa-devel] " Pierre-Louis Bossart
2019-02-22 21:52                     ` Pierre-Louis Bossart
2019-02-23 16:42                     ` [alsa-devel] " xiang xiao
2019-02-23 16:42                       ` xiang xiao
2019-02-25 10:16                 ` [Sound-open-firmware] [alsa-devel] " Srinivas Kandagatla
2019-02-25 10:16                   ` [Sound-open-firmware] " Srinivas Kandagatla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22872b53-338f-df35-8682-129b2db83b7e@linux.intel.com \
    --to=yang.jie@linux.intel.com \
    --cc=alan@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@gmail.com \
    --cc=kumar.gala@linaro.org \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --cc=wendy.liang@xilinx.com \
    --cc=xiaoxiang781216@gmail.com \
    --cc=xiaoxiang@xiaomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.