March 2020 - Sound-open-firmware - mailman.alsa-project.org

Re: [Sound-open-firmware] [PATCH 2/5] ASoC: SOF: imx: fix undefined reference issue
by Daniel Baluta 31 Mar '20

31 Mar '20

On Tue, Mar 31, 2020 at 3:25 PM Mark Brown <broonie(a)kernel.org> wrote: > > On Thu, Mar 19, 2020 at 09:49:54PM +0200, Daniel Baluta wrote: > > From: Daniel Baluta <daniel.baluta(a)nxp.com> > > > Fixes: f9ad75468453 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF > > dependency") > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > > Signed-off-by: Daniel Baluta <daniel.baluta(a)nxp.com> > > This has you as the author but you list a signoff by Pierre before you? Patch was initially designed by Pierre [1] when in the internal SOF tree we already had the I.MX8M patches. Whereas, in the current patch series I firstly fix the i.MX8 then I add support for i.MX8M. Should I go back and put Pierre as original author? [1] https://github.com/thesofproject/linux/commit/0c7dcfee80d96a8e75684178ab738…

1 0

[Sound-open-firmware] [PATCH 0/5] Add support for SOF on i.MX8M
by Daniel Baluta 31 Mar '20

31 Mar '20

From: Daniel Baluta <daniel.baluta(a)nxp.com> This patch series adds support for SOF on i.MX8M family. First board from this family that has a DSP is i.MX8MP. First 2 patches are trying to fix some compilation issues, the next two are adding the imx8m support and the last one adds the devicetree binding. Daniel Baluta (4): ASoC: SOF: imx: fix undefined reference issue ASoC: SOF: imx: Add i.MX8M HW support ASoC: SOF: Add i.MX8MP device descriptor dt-bindings: dsp: fsl: Add fsl,imx8mp-dsp entry YueHaibing (1): ASoC: SOF: imx8: Fix randbuild error .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 + sound/soc/sof/imx/Kconfig | 32 +- sound/soc/sof/imx/Makefile | 2 + sound/soc/sof/imx/imx8m.c | 279 ++++++++++++++++++ sound/soc/sof/sof-of-dev.c | 14 + 5 files changed, 325 insertions(+), 4 deletions(-) create mode 100644 sound/soc/sof/imx/imx8m.c -- 2.17.1

2 6

Re: [Sound-open-firmware] [PATCH 0/2] ASoC: SOF: initialise work immediately
by Guennadi Liakhovetski 25 Mar '20

25 Mar '20

On Tue, Mar 24, 2020 at 02:48:22PM +0000, Mark Brown wrote: > On Tue, Mar 24, 2020 at 02:58:56PM +0100, Guennadi Liakhovetski wrote: > > On Tue, Mar 24, 2020 at 01:30:42PM +0000, Mark Brown wrote: > > > > As documented in submitting-patches.rst please send patches to the > > > maintainers for the code you would like to change. The normal kernel > > > workflow is that people apply patches from their inboxes, if they aren't > > > copied they are likely to not see the patch at all and it is much more > > > difficult to apply patches. > > > I know that different maintainers have different preferences. For example > > in the subsysteem, where I'd worked for about 10 years the maintainer > > preferred not to be CCed on patches, he preferred to pick up patches from > > his mailing list folders, or whatever arrangement his mail filters > > provided for. I learned already that in ALSA / ASoC it's usual to CC > > maintainers. But I wasn't sure whether that also holds for larger patch > > series. E.g. my main patch series now consists of 14 patches, so, I > > thought, that maybe you would rather not receive multiple copies of the > > entire seriees for each new version both directly in your inbox and in > > the mailing list folder. Or is it indeed your preference to always be > > CCed on all patches? I apologise for re-iterating a question, that > > probably had been addressed multiple times before, maybe it's worth > > documenting this somewhere on ALSA web? > > Yes, copy me on patches. This is, as covered in what I wrote above, the > standard and documented approach for the kernel - unless you explicitly > know that there is some unusual approach for a specific subsystem you > should assume that if you want people to see your patches you need to > send the patches to them. Got it, thanks!

1 0

Re: [Sound-open-firmware] [PATCH 0/2] ASoC: SOF: initialise work immediately
by Guennadi Liakhovetski 25 Mar '20

25 Mar '20

Hi Mark, On Tue, Mar 24, 2020 at 01:30:42PM +0000, Mark Brown wrote: > On Tue, Mar 24, 2020 at 01:29:19PM +0100, Guennadi Liakhovetski wrote: > > Fix uninitialised work errors by moving initialisation to directly > > after allocation. > > > > Guennadi Liakhovetski (2): > > ASoC: SOF: (cosmetic) use for_each_pcm_streams() in sof_dai_load() > > ASoC: SOF: fix uninitialised "work" with VirtIO > > As documented in submitting-patches.rst please send patches to the > maintainers for the code you would like to change. The normal kernel > workflow is that people apply patches from their inboxes, if they aren't > copied they are likely to not see the patch at all and it is much more > difficult to apply patches. An update: these patches got merged into the SOF tree, so, no need to merge them to ASoC directly. Thanks Guennadi

1 0

[Sound-open-firmware] [PATCH 0/2] ASoC: SOF: initialise work immediately
by Guennadi Liakhovetski 24 Mar '20

24 Mar '20

Fix uninitialised work errors by moving initialisation to directly after allocation. Guennadi Liakhovetski (2): ASoC: SOF: (cosmetic) use for_each_pcm_streams() in sof_dai_load() ASoC: SOF: fix uninitialised "work" with VirtIO sound/soc/sof/pcm.c | 4 +--- sound/soc/sof/sof-audio.h | 3 +++ sound/soc/sof/topology.c | 17 ++++++++++++----- 3 files changed, 16 insertions(+), 8 deletions(-) -- 1.9.3

2 4

Re: [Sound-open-firmware] [PATCH 0/2] ASoC: SOF: initialise work immediately
by Guennadi Liakhovetski 24 Mar '20

24 Mar '20

Hi Mark, On Tue, Mar 24, 2020 at 01:30:42PM +0000, Mark Brown wrote: > On Tue, Mar 24, 2020 at 01:29:19PM +0100, Guennadi Liakhovetski wrote: > > Fix uninitialised work errors by moving initialisation to directly > > after allocation. > > > > Guennadi Liakhovetski (2): > > ASoC: SOF: (cosmetic) use for_each_pcm_streams() in sof_dai_load() > > ASoC: SOF: fix uninitialised "work" with VirtIO > > As documented in submitting-patches.rst please send patches to the > maintainers for the code you would like to change. The normal kernel > workflow is that people apply patches from their inboxes, if they aren't > copied they are likely to not see the patch at all and it is much more > difficult to apply patches. I know that different maintainers have different preferences. For example in the subsysteem, where I'd worked for about 10 years the maintainer preferred not to be CCed on patches, he preferred to pick up patches from his mailing list folders, or whatever arrangement his mail filters provided for. I learned already that in ALSA / ASoC it's usual to CC maintainers. But I wasn't sure whether that also holds for larger patch series. E.g. my main patch series now consists of 14 patches, so, I thought, that maybe you would rather not receive multiple copies of the entire seriees for each new version both directly in your inbox and in the mailing list folder. Or is it indeed your preference to always be CCed on all patches? I apologise for re-iterating a question, that probably had been addressed multiple times before, maybe it's worth documenting this somewhere on ALSA web? Thanks Guennadi

1 0

[Sound-open-firmware] [PATCH] ASoC: SOF: fix uninitialised "work" with VirtIO
by Guennadi Liakhovetski 23 Mar '20

23 Mar '20

In the VirtIO case the sof_pcm_open() function isn't called on the host during guest streaming, which then leaves "work" structures uninitialised. However it is then used to handle position update messages from the DSP. Move their initialisation to immediately after allocation of the containing structure. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> --- This is a re-send of "[PATCH 08/14] ASoC: SOF: fix uninitialised "work" with VirtIO" as suggested by Mark, also taking into account a comment from Ranjani - thanks. Note: I haven't sent patches before from mutt, hope this will work, if not - will have to re-send. sound/soc/sof/pcm.c | 4 +--- sound/soc/sof/sof-audio.h | 3 +++ sound/soc/sof/topology.c | 17 ++++++++++++----- 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c index f4769e1..47cd741 100644 --- a/sound/soc/sof/pcm.c +++ b/sound/soc/sof/pcm.c @@ -57,7 +57,7 @@ static int sof_pcm_dsp_params(struct snd_sof_pcm *spcm, struct snd_pcm_substream /* * sof pcm period elapse work */ -static void sof_pcm_period_elapsed_work(struct work_struct *work) +void snd_sof_pcm_period_elapsed_work(struct work_struct *work) { struct snd_sof_pcm_stream *sps = container_of(work, struct snd_sof_pcm_stream, @@ -475,8 +475,6 @@ static int sof_pcm_open(struct snd_soc_component *component, dev_dbg(component->dev, "pcm: open stream %d dir %d\n", spcm->pcm.pcm_id, substream->stream); - INIT_WORK(&spcm->stream[substream->stream].period_elapsed_work, - sof_pcm_period_elapsed_work); caps = &spcm->pcm.caps[substream->stream]; diff --git a/sound/soc/sof/sof-audio.h b/sound/soc/sof/sof-audio.h index eacd10e..bf65f31a 100644 --- a/sound/soc/sof/sof-audio.h +++ b/sound/soc/sof/sof-audio.h @@ -11,6 +11,8 @@ #ifndef __SOUND_SOC_SOF_AUDIO_H #define __SOUND_SOC_SOF_AUDIO_H +#include <linux/workqueue.h> + #include <sound/soc.h> #include <sound/control.h> #include <sound/sof/stream.h> /* needs to be included before control.h */ @@ -189,6 +191,7 @@ struct snd_sof_pcm *snd_sof_find_spcm_comp(struct snd_soc_component *scomp, struct snd_sof_pcm *snd_sof_find_spcm_pcm_id(struct snd_soc_component *scomp, unsigned int pcm_id); void snd_sof_pcm_period_elapsed(struct snd_pcm_substream *substream); +void snd_sof_pcm_period_elapsed_work(struct work_struct *work); /* * Mixer IPC diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 058de94..fe8ba3e 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -9,6 +9,7 @@ // #include <linux/firmware.h> +#include <linux/workqueue.h> #include <sound/tlv.h> #include <sound/pcm_params.h> #include <uapi/sound/sof/tokens.h> @@ -2448,7 +2449,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index, struct snd_soc_tplg_stream_caps *caps; struct snd_soc_tplg_private *private = &pcm->priv; struct snd_sof_pcm *spcm; - int stream = SNDRV_PCM_STREAM_PLAYBACK; + int stream; int ret = 0; /* nothing to do for BEs atm */ @@ -2460,8 +2461,12 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index, return -ENOMEM; spcm->scomp = scomp; - spcm->stream[SNDRV_PCM_STREAM_PLAYBACK].comp_id = COMP_ID_UNASSIGNED; - spcm->stream[SNDRV_PCM_STREAM_CAPTURE].comp_id = COMP_ID_UNASSIGNED; + + for_each_pcm_streams(stream) { + spcm->stream[stream].comp_id = COMP_ID_UNASSIGNED; + INIT_WORK(&spcm->stream[stream].period_elapsed_work, + snd_sof_pcm_period_elapsed_work); + } spcm->pcm = *pcm; dev_dbg(scomp->dev, "tplg: load pcm %s\n", pcm->dai_name); @@ -2482,8 +2487,10 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index, if (!spcm->pcm.playback) goto capture; + stream = SNDRV_PCM_STREAM_PLAYBACK; + dev_vdbg(scomp->dev, "tplg: pcm %s stream tokens: playback d0i3:%d\n", - spcm->pcm.pcm_name, spcm->stream[0].d0i3_compatible); + spcm->pcm.pcm_name, spcm->stream[stream].d0i3_compatible); caps = &spcm->pcm.caps[stream]; @@ -2513,7 +2520,7 @@ static int sof_dai_load(struct snd_soc_component *scomp, int index, return ret; dev_vdbg(scomp->dev, "tplg: pcm %s stream tokens: capture d0i3:%d\n", - spcm->pcm.pcm_name, spcm->stream[1].d0i3_compatible); + spcm->pcm.pcm_name, spcm->stream[stream].d0i3_compatible); caps = &spcm->pcm.caps[stream]; -- 1.9.3

2 3

[Sound-open-firmware] Static pipeline and dsp only use case
by Daniel Baluta 23 Mar '20

23 Mar '20

Hi Liam, We have now basic support for our i.MX8 boards in Qemu. Do you know if we can continue development/testing having only the DSP side? So far none of the i.MX8 have qemu support. Looking at src/schedule/task.c I noticed that we can create a static pipeline but how do we trigger processing? Our goal for qemu right now is to complete the DSP part and validate some processing algorithms. Thanks for your help!

3 2

Re: [Sound-open-firmware] [PATCH 06/14] ASoC: SOF: add a power status IPC
by Guennadi Liakhovetski 23 Mar '20

23 Mar '20

On Fri, Mar 20, 2020 at 04:39:48PM +0000, Mark Brown wrote: > On Fri, Mar 20, 2020 at 04:07:27PM +0100, Guennadi Liakhovetski wrote: > > On Fri, Mar 20, 2020 at 02:27:32PM +0100, Guennadi Liakhovetski wrote: > > > > No, this isn't a completion - it's a counter. I've used atomic variables > > > before, I cannot remember seeing any difficulties with their correct use > > > described. Do you have a pointer? > > > Actually I'd even say this isn't a problem. I think it's safe to say, you > > won't suspend and resume your audio interface more often than every 10 > > seconds. That makes under 3200000 cycles per year. Even with 31 bits for a > > signed integer that makes more than 600 years. I think we're safe. > > The problem is that atomics are just incredibly error prone - for > example they're just a plain number, they're usually counting something > which is not being locked so you have to be careful any time you do > anything around them. Their lack of structure makes them harder to > reason about than most other locking primitives, often harder than it's > worth. Ok, understand, but do you see any problems with this specific use case? Thinking about possible replacements - it isn't a case for a ref-count, because it isn't a get-put scenario. We really just need to count a specific event - DSP reboots. It can be the case that this counter doesn't need to be atomic at all. When it is read, the DSP is guaranteed to be up and running - I think. So no race would be possible. I can try to think about this more carefully and maybe make it a normal unprotected counter. But I don't think it has to be protected even better than what these patches are doing. Thanks Guennadi

1 0

[Sound-open-firmware] [PATCH 00/12] ASoC: SOF DSP virtualisation
by Guennadi Liakhovetski 20 Mar '20

20 Mar '20

This patch series extends the SOF driver to add support for DSP virtualisation to ASoC. It is built on top of VirtIO, contains a guest driver and a vhost in-kernel guest driver. This version supports a single playback and a single capture interface on the guest. The specific guest audio topology is supplied by the host from a file, specified on the QEMU command line. This solution is designed to use advanced DSP functionality, available on the host. In case no DSP is available on the host, a fall-back should be provided in the future to the pure audio virtualisation standard, currently developed by OASIS. Extensive documentation is available at [1]. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski at linux.intel.com> v2: one patch merged, one patch resubmitted separately, otherwise no changes. [1] https://thesofproject.github.io/latest/developer_guides/virtualization/virt… Guennadi Liakhovetski (12): ASoC: add function parameters to enable forced path pruning ASoC: SOF: extract firmware-related operation into a function ASoC: SOF: VirtIO: make a function global vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl ASoC: SOF: support IPC with immediate response ASoC: SOF: add a power status IPC ASoC: SOF: add two helper lookup functions ASoC: SOF: add a VirtIO DSP driver ASoC: SOF: add a vhost driver: sound part vhost: add an SOF DSP driver ASoC: SOF: VirtIO: free guest pipelines upon termination ASoC: SOF: VirtIO: enable simultaneous playback and capture drivers/vhost/Kconfig | 7 + drivers/vhost/Makefile | 5 + drivers/vhost/dsp.c | 731 ++++++++++++++++++++++ include/sound/soc-dpcm.h | 28 +- include/sound/soc-topology.h | 3 + include/sound/sof.h | 4 + include/sound/sof/header.h | 3 + include/sound/sof/topology.h | 1 + include/sound/sof/virtio.h | 206 +++++++ include/uapi/linux/vhost.h | 9 +- include/uapi/linux/vhost_types.h | 7 + include/uapi/linux/virtio_ids.h | 1 + sound/soc/soc-compress.c | 2 +- sound/soc/soc-dapm.c | 8 +- sound/soc/soc-pcm.c | 98 ++- sound/soc/sof/Kconfig | 8 + sound/soc/sof/Makefile | 8 + sound/soc/sof/core.c | 114 ++-- sound/soc/sof/ipc.c | 39 +- sound/soc/sof/loader.c | 4 + sound/soc/sof/ops.h | 10 +- sound/soc/sof/pcm.c | 15 +- sound/soc/sof/pm.c | 4 + sound/soc/sof/sof-audio.c | 33 + sound/soc/sof/sof-audio.h | 21 + sound/soc/sof/sof-priv.h | 54 ++ sound/soc/sof/topology.c | 71 ++- sound/soc/sof/vhost-be.c | 1248 ++++++++++++++++++++++++++++++++++++++ sound/soc/sof/virtio-fe.c | 922 ++++++++++++++++++++++++++++ 29 files changed, 3555 insertions(+), 109 deletions(-) create mode 100644 drivers/vhost/dsp.c create mode 100644 include/sound/sof/virtio.h create mode 100644 sound/soc/sof/vhost-be.c create mode 100644 sound/soc/sof/virtio-fe.c -- 1.9.3

1 12

Re: [Sound-open-firmware] [PATCH 06/14] ASoC: SOF: add a power status IPC
by Guennadi Liakhovetski 20 Mar '20

20 Mar '20

On Fri, Mar 20, 2020 at 12:19:52PM +0000, Mark Brown wrote: > On Fri, Mar 20, 2020 at 12:52:03PM +0100, Guennadi Liakhovetski wrote: > > On Fri, Mar 13, 2020 at 02:39:56PM +0000, Mark Brown wrote: > > > On Thu, Mar 12, 2020 at 03:44:21PM +0100, Guennadi Liakhovetski wrote: > > > > > #endif > > > > + atomic_set(&sdev->reset_count, 0); > > > > dev_set_drvdata(dev, sdev); > > > > Do we really need to use atomics for this? They are hard to use > > > correctly. > > > This variable is accessed from 2 contexts: it's incremented by the SOF > > driver, when the firmware has booted and it's read by the SOF > > VirtIO backend vhost-be.c when receiving a resume request from the guest. > > Timewise the variable will only be incremented during the DSP resume / > > power up, while the VirtIO back end is waiting for the resume to complete in > > pm_runtime_get_sync(). And only after that it reads the variable. But that > > can happen on different CPUs. Whereas I think that runtime PM will sync > > caches somewhere during the process, I think it is better to access the > > variable in an SMP-safe way, e.g. using atomic operations. > > That doesn't address my concern - to repeat, my concern is that atomics > are hard to use correctly. Is there no other concurrency primitive (for > example this sounds like a completion) which can be used? No, this isn't a completion - it's a counter. I've used atomic variables before, I cannot remember seeing any difficulties with their correct use described. Do you have a pointer? Thinking about it, one problem I see is wrapping, it isn't currently handled, but that would happen after quite a few PM suspend / resume cycles... Still it can and should be fixed. But this isn't the concern, that you have? Thanks Guennadi

1 1

Re: [Sound-open-firmware] [PATCH 06/14] ASoC: SOF: add a power status IPC
by Guennadi Liakhovetski 20 Mar '20

20 Mar '20

Hi Mark, On Fri, Mar 13, 2020 at 02:39:56PM +0000, Mark Brown wrote: > On Thu, Mar 12, 2020 at 03:44:21PM +0100, Guennadi Liakhovetski wrote: > > > #endif > > + atomic_set(&sdev->reset_count, 0); > > dev_set_drvdata(dev, sdev); > > Do we really need to use atomics for this? They are hard to use > correctly. This variable is accessed from 2 contexts: it's incremented by the SOF driver, when the firmware has booted and it's read by the SOF VirtIO backend vhost-be.c when receiving a resume request from the guest. Timewise the variable will only be incremented during the DSP resume / power up, while the VirtIO back end is waiting for the resume to complete in pm_runtime_get_sync(). And only after that it reads the variable. But that can happen on different CPUs. Whereas I think that runtime PM will sync caches somewhere during the process, I think it is better to access the variable in an SMP-safe way, e.g. using atomic operations. > > #include "ops.h" > > @@ -617,6 +618,9 @@ int snd_sof_run_firmware(struct snd_sof_dev *sdev) > > /* fw boot is complete. Update the active cores mask */ > > sdev->enabled_cores_mask = init_core_mask; > > > > + /* increment reset count */ > > + atomic_add(1, &sdev->reset_count); > > + > > We at no point seem to read from this reset counter? I can't figure out > from this commit what it's doing. It's used in vhost-be.c (patch 10/14). Thanks Guennadi

1 0

[Sound-open-firmware] [PATCH v2 0/2] Add generic FSL CPU DAI driver
by Daniel Baluta 16 Mar '20

16 Mar '20

From: Daniel Baluta <daniel.baluta(a)nxp.com> On platforms with a DSP we need to split the resource handling between Application Processor (AP) and DSP. On platforms where the DSP doesn't have an easy access to resources, the AP will take care of configuring them. Resources handled by this generic driver are: clocks, power domains, pinctrl. Changes since v1: - added dt-bindings patch - add missing signed-off-by - do not hardcode the name of DAI driver but derive it from newly introduced dai_index property. Daniel Baluta (2): dt-bindings: sound: Add FSL CPU DAI bindings ASoC: fsl: Add generic CPU DAI driver .../devicetree/bindings/sound/fsl,dai.yaml | 97 ++++++ sound/soc/fsl/Kconfig | 8 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_dai.c | 288 ++++++++++++++++++ 4 files changed, 395 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,dai.yaml create mode 100644 sound/soc/fsl/fsl_dai.c -- 2.17.1

4 6

[Sound-open-firmware] Question about PM sleep
by Daniel Baluta 13 Mar '20

13 Mar '20

Hi Ranjani, While doing PM resume I get this warning message: root@imx8qxpmek:~# arecord -Dhw:0,0 -f S32_LE -r 48000 -c 2 z3.wav Recording WAVE 'z3.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo Suspended. Trying resume. Failed. Restarting stream. Done. Any idea what could cause it? It is because my stream doesn't really support resume? Still investigating this, but sending you this email because maybe you got hit by this issue. thanks, Daniel.

3 4

[Sound-open-firmware] [PATCH 00/14] ASoC: SOF DSP virtualisation
by Guennadi Liakhovetski 13 Mar '20

13 Mar '20

This patch series extends the SOF driver to add support for DSP virtualisation to ASoC. It is built on top of VirtIO, contains a guest driver and a vhost in-kernel guest driver. This version supports a single playback and a single capture interface on the guest. The specific guest audio topology is supplied by the host from a file, specified on the QEMU command line. This solution is designed to use advanced DSP functionality, available on the host. In case no DSP is available on the host, a fall-back should be provided in the future to the pure audio virtualisation standard, currently developed by OASIS. Extensive documentation is available at [1]. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> [1] https://thesofproject.github.io/latest/developer_guides/virtualization/virt… Guennadi Liakhovetski (14): ASoC: add function parameters to enable forced path pruning ASoC: SOF: extract firmware-related operation into a function ASoC: SOF: VirtIO: make a function global vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl ASoC: SOF: support IPC with immediate response ASoC: SOF: add a power status IPC ASoC: SOF: add two helper lookup functions ASoC: SOF: fix uninitialised "work" with VirtIO ASoC: SOF: add a VirtIO DSP driver ASoC: SOF: add a vhost driver: sound part vhost: add an SOF DSP driver ASoC: SOF: VirtIO: check guest component IDs ASoC: SOF: VirtIO: free guest pipelines upon termination ASoC: SOF: VirtIO: enable simultaneous playback and capture drivers/vhost/Kconfig | 7 + drivers/vhost/Makefile | 5 + drivers/vhost/dsp.c | 731 ++++++++++++++++++++++ include/sound/soc-dpcm.h | 28 +- include/sound/soc-topology.h | 3 + include/sound/sof.h | 4 + include/sound/sof/header.h | 3 + include/sound/sof/topology.h | 1 + include/sound/sof/virtio.h | 206 +++++++ include/uapi/linux/vhost.h | 9 +- include/uapi/linux/vhost_types.h | 7 + include/uapi/linux/virtio_ids.h | 1 + sound/soc/soc-compress.c | 2 +- sound/soc/soc-dapm.c | 8 +- sound/soc/soc-pcm.c | 98 ++- sound/soc/sof/Kconfig | 8 + sound/soc/sof/Makefile | 8 + sound/soc/sof/core.c | 114 ++-- sound/soc/sof/ipc.c | 39 +- sound/soc/sof/loader.c | 4 + sound/soc/sof/ops.h | 10 +- sound/soc/sof/pcm.c | 17 +- sound/soc/sof/pm.c | 4 + sound/soc/sof/sof-audio.c | 33 + sound/soc/sof/sof-audio.h | 21 + sound/soc/sof/sof-priv.h | 54 ++ sound/soc/sof/topology.c | 76 ++- sound/soc/sof/vhost-be.c | 1248 ++++++++++++++++++++++++++++++++++++++ sound/soc/sof/virtio-fe.c | 922 ++++++++++++++++++++++++++++ 29 files changed, 3560 insertions(+), 111 deletions(-) create mode 100644 drivers/vhost/dsp.c create mode 100644 include/sound/sof/virtio.h create mode 100644 sound/soc/sof/vhost-be.c create mode 100644 sound/soc/sof/virtio-fe.c -- 1.9.3

2 15

[Sound-open-firmware] [PATCH v2 0/2] ASoC: SOF: preparatory patches
by Guennadi Liakhovetski 12 Mar '20

12 Mar '20

2 preparatory patches for the SOF virtualisation work. No functional changes, only some code refactoring and exporting of helper functions. v2: rebase, no changes otherwise. Thanks Guennadi Guennadi Liakhovetski (2): ASoC: (cosmetic) simplify dpcm_prune_paths() ASoC: export DPCM runtime update functions include/sound/soc-dpcm.h | 4 +-- sound/soc/soc-dapm.c | 8 +++--- sound/soc/soc-pcm.c | 68 +++++++++++++++++++++++++----------------------- 3 files changed, 42 insertions(+), 38 deletions(-) -- 1.9.3

3 5

Re: [Sound-open-firmware] [PATCH 0/3] [RESEND] ASoC: SOF: preparatory patches
by Guennadi Liakhovetski 12 Mar '20

12 Mar '20

On Thu, Mar 12, 2020 at 12:15:49PM +0000, Mark Brown wrote: > On Thu, Mar 12, 2020 at 12:45:37PM +0100, Guennadi Liakhovetski wrote: > > On Tue, Mar 10, 2020 at 12:50:56PM +0000, Mark Brown wrote: > > > > How does this relate to the virtio audio spec that's currently under > > > review? > > > The spec under discussion is only for simple audio virtualisation with fixed > > roles and topologies. With our approach guests get access to advanced DSP > > capabilities. The virtualisation approach under discussion can be a fallback > > for cases when no DSP has been detected on the host. > > So they're orthogonal :/ Have you proposed your spec yet? > > > > It looks to be doing something much lower level than that. > > > I am concerned that this looks to be exposing DPCM as a virtio ABI, > > > we're trying to replace it as an internal API never mind ABI. > > > You mean that our approach works at the widget level, which is a part of the > > DPCM API? Well there is a translation layer between our ABI and DPCM. And by > > virtue of the same argument don't we already have DPCM as an ABI on the > > opposite side of SOF - in its IPC ABI? Largely this virtualisation approach > > doesn't add new interfaces, it re-uses the SOF IPC ABI, which is also one of > > its advantages. > > Please bear in mind that the page you linked to is very high level and > I've not seen the actual spec or anything. The page and your mails both > talk about DPCM so it sounds like that's a part of the interface. Let me rebase my current stack and post it here, stay tuned :-) Thanks Guennadi

1 0

Re: [Sound-open-firmware] [PATCH 0/3] [RESEND] ASoC: SOF: preparatory patches
by Guennadi Liakhovetski 12 Mar '20

12 Mar '20

Hi, On Tue, Mar 10, 2020 at 12:50:56PM +0000, Mark Brown wrote: > On Mon, Mar 09, 2020 at 05:05:06PM -0500, Pierre-Louis Bossart wrote: > > > To get a better picture of the directions, reviewers are invited to take a > > look at the in-depth documentation written by Guennadi since the initial > > patches were shared. This documentation was reviewed by Liam and me and is > > really required to understand the concepts: > > > https://thesofproject.github.io/latest/developer_guides/virtualization/virt… > > How does this relate to the virtio audio spec that's currently under > review? The spec under discussion is only for simple audio virtualisation with fixed roles and topologies. With our approach guests get access to advanced DSP capabilities. The virtualisation approach under discussion can be a fallback for cases when no DSP has been detected on the host. > It looks to be doing something much lower level than that. > I am concerned that this looks to be exposing DPCM as a virtio ABI, > we're trying to replace it as an internal API never mind ABI. You mean that our approach works at the widget level, which is a part of the DPCM API? Well there is a translation layer between our ABI and DPCM. And by virtue of the same argument don't we already have DPCM as an ABI on the opposite side of SOF - in its IPC ABI? Largely this virtualisation approach doesn't add new interfaces, it re-uses the SOF IPC ABI, which is also one of its advantages. Thanks Guennadi

1 0

Re: [Sound-open-firmware] [PATCH 2/3] ASoC: add function parameters to enable forced path pruning
by Guennadi Liakhovetski 11 Mar '20

11 Mar '20

On Wed, Mar 11, 2020 at 12:41:02PM +0000, Mark Brown wrote: > On Wed, Mar 11, 2020 at 01:36:17PM +0100, Guennadi Liakhovetski wrote: > > On Wed, Mar 11, 2020 at 12:25:31PM +0000, Mark Brown wrote: > > > > It's still not clear to me what the issue is here. If something is > > > making a modification to the graph which needs a recheck or update I'd > > > expect that these things happen along with that modification. I don't > > > understand what you're saying about not being able to reproduce > > > scenarios or adding things "on top". > > > VirtIO support. That function currently exists in the kernel, but I don't > > have a test-case to verify its work, to see it called and actually perform > > the pruning. So I don't know how it is supposed to work. And because of > > that I cannot fix my VirtIO use case to use that function properly, without > > forcing it with an additional parameter. > > I think you need to include this with your VirtIO series. That was also my original intention, personally I also would find it difficult to review this kind of work without context. So, would you prefer me to drop this series completely and re-send it with the whole series or should I just drop #2 and resend #1 and #3? Thanks Guennadi

1 0

[Sound-open-firmware] SOF Versioning and stable releases
by Daniel Baluta 11 Mar '20

11 Mar '20

Hi Liam, What is the current stable release? And what is the release versioning scheme. I think it is 1.4-stable right? We plan to create a stable branch for imx. Maybe 1.4-stable-imx and put it into our internal Yocto release. Also, for sof-bin release repo how we will push the binaries? I mean just compile it by yourself and push it there. Or we let a travis build to do the job so that we can also have the compile log.

1 0

Re: [Sound-open-firmware] [PATCH 2/3] ASoC: add function parameters to enable forced path pruning
by Guennadi Liakhovetski 11 Mar '20

11 Mar '20

Hi Mark, On Wed, Mar 11, 2020 at 12:25:31PM +0000, Mark Brown wrote: > On Wed, Mar 11, 2020 at 08:41:27AM +0100, Guennadi Liakhovetski wrote: > > On Tue, Mar 10, 2020 at 12:45:44PM +0000, Mark Brown wrote: > > > > So why doesn't DPCM recognize that the path is inactive and why is it > > > better to do this than fix whatever the issue is there? > > > Of course that would be better abd I'd much prefer that. Unfortunately I > > haven't been able to find a single scenario in which those paths would be > > exercised. As far as I understand path pruning should take place e.g. > > when a mixer modifies audio routing and as a result disables a certain > > pipeline, which is then pruned. If I could reproduce such a scenario I > > would be able to first check whether it's working, then see exactly how > > it is working and then see how best to add my use case to it. Since I > > wasn't able to find such a scenario, my only option was to preserve > > the current state and add my own path "on top." I'd be happy to try the > > other path too, I just need a use case, that I can reproduce. > > It's still not clear to me what the issue is here. If something is > making a modification to the graph which needs a recheck or update I'd > expect that these things happen along with that modification. I don't > understand what you're saying about not being able to reproduce > scenarios or adding things "on top". I mean, that I don't have a test-case to test dpcm_prune_paths() without my VirtIO support. That function currently exists in the kernel, but I don't have a test-case to verify its work, to see it called and actually perform the pruning. So I don't know how it is supposed to work. And because of that I cannot fix my VirtIO use case to use that function properly, without forcing it with an additional parameter. Thanks Guennadi

1 0

Re: [Sound-open-firmware] [PATCH 2/3] ASoC: add function parameters to enable forced path pruning
by Guennadi Liakhovetski 11 Mar '20

11 Mar '20

Hi Mark, On Tue, Mar 10, 2020 at 12:45:44PM +0000, Mark Brown wrote: > On Mon, Mar 09, 2020 at 06:07:48PM +0100, Guennadi Liakhovetski wrote: > > > soc_dpcm_runtime_update() to activate an audio path and update audio > > routing. When streaming is stopped, the vhost driver calls > > soc_dpcm_runtime_update() and snd_soc_runtime_deactivate(). The latter > > doesn't work at the moment, because the DPCM doesn't recognise the > > path as inactive. We address this by adding a "mode" parameter to > > soc_dpcm_runtime_update(). If virtualisation isn't used, the current > > behaviour isn't affected. > > So why doesn't DPCM recognize that the path is inactive and why is it > better to do this than fix whatever the issue is there? Of course that would be better abd I'd much prefer that. Unfortunately I haven't been able to find a single scenario in which those paths would be exercised. As far as I understand path pruning should take place e.g. when a mixer modifies audio routing and as a result disables a certain pipeline, which is then pruned. If I could reproduce such a scenario I would be able to first check whether it's working, then see exactly how it is working and then see how best to add my use case to it. Since I wasn't able to find such a scenario, my only option was to preserve the current state and add my own path "on top." I'd be happy to try the other path too, I just need a use case, that I can reproduce. Thanks Guennadi

1 0

Re: [Sound-open-firmware] [PATCH 0/3] [RESEND] ASoC: SOF: preparatory patches
by Pierre-Louis Bossart 10 Mar '20

10 Mar '20

On 3/10/20 7:50 AM, Mark Brown wrote: > On Mon, Mar 09, 2020 at 05:05:06PM -0500, Pierre-Louis Bossart wrote: > >> To get a better picture of the directions, reviewers are invited to take a >> look at the in-depth documentation written by Guennadi since the initial >> patches were shared. This documentation was reviewed by Liam and me and is >> really required to understand the concepts: > >> https://thesofproject.github.io/latest/developer_guides/virtualization/virt… > > How does this relate to the virtio audio spec that's currently under > review? It looks to be doing something much lower level than that. Mark, to avoid any ambiguity, what 'virtio audio spec that's currently under review' are you referring to? > I am concerned that this looks to be exposing DPCM as a virtio ABI, > we're trying to replace it as an internal API never mind ABI. Valid point indeed.

1 0

[Sound-open-firmware] [PATCH 0/3] [RESEND] ASoC: SOF: preparatory patches
by Guennadi Liakhovetski 09 Mar '20

09 Mar '20

This is the first set of patches for the SOF virtualisation work. We send these patches first because they touch the ASoC core. 2 of them are mostly cosmetic with no functional changes, but patch 2/3 might cause some discussions. Please review and comment. Thanks Guennadi Guennadi Liakhovetski (3): ASoC: (cosmetic) simplify dpcm_prune_paths() ASoC: add function parameters to enable forced path pruning ASoC: export DPCM runtime update functions include/sound/soc-dpcm.h | 30 ++++++++--- sound/soc/soc-compress.c | 2 +- sound/soc/soc-dapm.c | 8 +-- sound/soc/soc-pcm.c | 130 +++++++++++++++++++++++++++++------------------ 4 files changed, 109 insertions(+), 61 deletions(-) -- 1.9.3

2 7

Re: [Sound-open-firmware] Getting error while building firmware binaries (I am building SOF from scratch)
by Liam Girdwood 03 Mar '20

03 Mar '20

Hi, On Mon, 2020-03-02 at 21:54 +0530, Akriti Verma wrote: > > Hi, > I am stuck at this since a long time an cannot come to a possible > solution. > I was trying to build firmware binaries and i ha cloned sof.git by > using the command :- > git clone https://github.com/thesofproject/sof.git > > While running the './scripts/xtensa-build-all.sh -a' command, i get > certain > makefile errors as can be seen in the attached screenshot. > Have you built the compilers and installed it in your $PATH ? Can you confirm you have followed the instructions and are using a recent Linux distro. https://thesofproject.github.io/latest/getting_started/build-guide/build-fr… Thanks Liam > > I am unable to find a workaround for this problem and move further > with the building > > Thanks and regards > Akriti

1 0

[Sound-open-firmware] [Re]: Make error when building topology and tools
by Mohana Datta Yelugoti 02 Mar '20

02 Mar '20

Hi all, I am trying to building SOF from scratch by following through the official documentation guide [0]. I am getting errors when trying to build Topology and tools [1]. I am providing pastebin links to topology_log [2] and topology_error_log [3]. topology_log contains output to stdout and topology_error_log contains the output to stderr. I was able to build in docker successfully before. But, when i am trying to build from scratch, i encountered this error. Can someone guide me in solving this error. The system i am building runs on Ubuntu 19.19 eoan. My kernel version is 5.3.0-40-generic. Please feel free to ask for any other information, if i am missing any. Thank you for your time. Regards, ymdatta. References: ---------- [0]: https://thesofproject.github.io/latest/getting_started/build-guide/build-fr… [1]: https://thesofproject.github.io/latest/getting_started/build-guide/build-fr… [2]: https://paste.gnome.org/pffxkrwjm/cvhcko [3]: https://paste.gnome.org/pg9mefnet/crqsix

3 5