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

[Sound-open-firmware] [PATCH] ASoC: SOF: Update correct LED status at the first time usage of update_mute_led()
by Kai-Heng Feng 01 May '20

01 May '20

At the first time update_mute_led() gets called, if channels are already muted, the temp value equals to led_value as 0, skipping the following LED setting. So set led_value to -1 as an uninitialized state, to update the correct LED status at first time usage. Fixes: 5d43001ae436 ("ASoC: SOF: acpi led support for switch controls") Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/soc/sof/control.c | 4 ++-- sound/soc/sof/sof-audio.h | 2 +- sound/soc/sof/topology.c | 2 ++ 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/control.c b/sound/soc/sof/control.c index dfc412e2d956..6d63768d42aa 100644 --- a/sound/soc/sof/control.c +++ b/sound/soc/sof/control.c @@ -19,8 +19,8 @@ static void update_mute_led(struct snd_sof_control *scontrol, struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { - unsigned int temp = 0; - unsigned int mask; + int temp = 0; + int mask; int i; mask = 1U << snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); diff --git a/sound/soc/sof/sof-audio.h b/sound/soc/sof/sof-audio.h index bf65f31af858..875a5fc13297 100644 --- a/sound/soc/sof/sof-audio.h +++ b/sound/soc/sof/sof-audio.h @@ -56,7 +56,7 @@ struct snd_sof_pcm { struct snd_sof_led_control { unsigned int use_led; unsigned int direction; - unsigned int led_value; + int led_value; }; /* ALSA SOF Kcontrol device */ diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index fe8ba3e05e08..ab2b69de1d4d 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -1203,6 +1203,8 @@ static int sof_control_load(struct snd_soc_component *scomp, int index, return ret; } + scontrol->led_ctl.led_value = -1; + dobj->private = scontrol; list_add(&scontrol->list, &sdev->kcontrol_list); return ret; -- 2.17.1

4 3

[Sound-open-firmware] [PATCH] ASoC: SOF: sort out Kconfig, again
by Arnd Bergmann 30 Apr '20

30 Apr '20

The imx8 config keeps causing issues: WARNING: unmet direct dependencies detected for SND_SOC_SOF_IMX8M Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=m] && SND_SOC_SOF_TOPLEVEL [=y] && SND_SOC_SOF_IMX_TOPLEVEL [=y] && IMX_DSP [=n] Selected by [m]: - SND_SOC_SOF_IMX_OF [=m] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=m] && SND_SOC_SOF_TOPLEVEL [=y] && SND_SOC_SOF_IMX_TOPLEVEL [=y] && SND_SOC_SOF_IMX8M_SUPPORT [=y] This is complicated by two drivers having dependencies on both platform specific drivers and the SND_SOC_SOF_OF framework code, and using an somewhat obscure method to build them the same way as the SOC_SOF_OF symbol (built-in or modular). My solution now ensures that the two drivers can only be enabled when the dependencies are met: - When the platform specific drivers are built-in, everything is fine, as SOC_SOF_OF is either =y or =m - When both are loadable modules, it also works, both for Kconfig and at runtime - When the hardware drivers are loadable modules or disabled, and SOC_SOF_OF=y, prevent the IMX_SOF_OF drivers from being turned on, as this would be broken. It seems that this is just an elaborate way to describe two tristate symbols that have straight dependencies, but maybe I'm missing some subtle point. It seems to always build for me now. Fixes: fe57a92c8858 ("ASoC: SOF: Add missing dependency on IMX_SCU") Fixes: afb93d716533 ("ASoC: SOF: imx: Add i.MX8M HW support") Fixes: cb0312f61c3e ("ASoC: SOF: imx: fix undefined reference issue") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/sof/imx/Kconfig | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig index f76660e91382..66684d7590f4 100644 --- a/sound/soc/sof/imx/Kconfig +++ b/sound/soc/sof/imx/Kconfig @@ -21,7 +21,8 @@ config SND_SOC_SOF_IMX_OF config SND_SOC_SOF_IMX8_SUPPORT bool "SOF support for i.MX8" - depends on IMX_SCU + depends on IMX_SCU=y || IMX_SCU=SND_SOC_SOF_IMX_OF + depends on IMX_DSP=y || IMX_DSP=SND_SOC_SOF_IMX_OF help This adds support for Sound Open Firmware for NXP i.MX8 platforms Say Y if you have such a device. @@ -29,14 +30,13 @@ config SND_SOC_SOF_IMX8_SUPPORT config SND_SOC_SOF_IMX8 tristate - depends on IMX_SCU - select IMX_DSP help This option is not user-selectable but automagically handled by 'select' statements at a higher level config SND_SOC_SOF_IMX8M_SUPPORT bool "SOF support for i.MX8M" + depends on IMX_DSP=y || IMX_DSP=SND_SOC_SOF_OF help This adds support for Sound Open Firmware for NXP i.MX8M platforms Say Y if you have such a device. @@ -44,7 +44,6 @@ config SND_SOC_SOF_IMX8M_SUPPORT config SND_SOC_SOF_IMX8M tristate - depends on IMX_DSP help This option is not user-selectable but automagically handled by 'select' statements at a higher level -- 2.26.0

4 7

[Sound-open-firmware] About sof and D0 D3 states, 'standby' and 'suspend to RAM'
by josep lladonosa capell 24 Apr '20

24 Apr '20

Hello, I have found[1] that sof driver works (for now?) only two power states: D0 (DSP ON) and D3 (DSP OFF). In a laptop with battery, not connected to AC, I have many "D0->D3->D0" state changes during system operation [3].When entering into to D0, all firmware is loaded again, DSP set up and so (obvious, as DSPs where off). My guess is that this transition happens in a power state transition lower than Suspend to RAM, i.e., Suspend-to-idle or Standby. [2] Should not be the transition to D3 state done in a kernel transition to S3 or higher only (Suspend to RAM, hibernate)? I have digged into the code and found the debug line in sound/soc/sof/intel/hda-codec.c: dev_dbg(bus->dev, "Turning i915 HDAC power %d\n", enable); and function hda_suspend is in hda-dsp.c: static int hda_suspend(struct snd_sof_dev *sdev, bool runtime_suspend) Regards, Josep [1]: https://thesofproject.github.io/latest/developer_guides/linux_driver/archit… [2]: https://www.kernel.org/doc/html/v5.6/admin-guide/pm/sleep-states.html#suspe… [3]: Log from a session in a laptop working on its battery (only D0 D3 transition debug lines): ++++++++++++++++++++++++++++ Apr 23 08:06:20 debian kernel: [ 1357.524900] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:23 debian kernel: [ 1359.967511] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:06:29 debian kernel: [ 1366.697617] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:06:32 debian kernel: [ 1368.976763] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:07:41 debian kernel: [ 1438.758013] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:07:44 debian kernel: [ 1440.968094] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:29 debian kernel: [ 1486.346591] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:32 debian kernel: [ 1488.968805] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:08:33 debian kernel: [ 1489.970170] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:08:35 debian kernel: [ 1492.134071] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:09:43 debian kernel: [ 1560.535211] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:09:46 debian kernel: [ 1563.180713] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:12 debian kernel: [ 1649.719864] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:15 debian kernel: [ 1652.347401] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:23 debian kernel: [ 1660.328147] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:26 debian kernel: [ 1662.895611] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:38 debian kernel: [ 1675.404116] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:41 debian kernel: [ 1678.023978] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:43 debian kernel: [ 1680.128389] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:45 debian kernel: [ 1682.563802] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:46 debian kernel: [ 1683.187391] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:48 debian kernel: [ 1685.358684] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:52 debian kernel: [ 1689.704048] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:55 debian kernel: [ 1692.350057] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:11:56 debian kernel: [ 1693.056443] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:11:58 debian kernel: [ 1695.315083] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:28 debian kernel: [ 1725.232502] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:30 debian kernel: [ 1727.379811] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:35 debian kernel: [ 1732.240686] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:38 debian kernel: [ 1734.816780] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:39 debian kernel: [ 1736.719892] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:42 debian kernel: [ 1739.340736] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:51 debian kernel: [ 1748.048546] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 Apr 23 08:12:53 debian kernel: [ 1750.688659] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 0 Apr 23 08:12:58 debian kernel: [ 1755.075835] sof-audio-pci 0000:00:1f.3: Turning i915 HDAC power 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 4

[Sound-open-firmware] Question about scheduling IPC task vs pipeline task
by Daniel Baluta 22 Apr '20

22 Apr '20

Hi Tomasz, Running aplay I get this timeout, on kernel side: sof-audio-of 3b6e8000.dsp: error: ipc timed out for 0x60040000 size 12 This is the command for SOF_IPC_STREAM_TRIG_START. What I notice on SOF side is: -> irq_handle (new message from SOF arrives) -> ipc_schedule_process -> schedule_ipc_task -> run: ipc_platform_do_cmd -> pipeline_trigger() -> schedule pipe_task -> then pipeline_copy starts to RUN Now the problem is that even if pipeline_copy() runs in a separate schedulable task, ipc_task doesn't get a chance to run so the reply for TRIGGER command isn't sent back to host hence the timeout. My question: Does pipeline_copy() runs in some special context so that normal EDF tasks can meet their deadline? I do have a slightly new firmware then the kernel, not sure about what recent changes have been done to firmware. thanks, Daniel.

3 4

[Sound-open-firmware] [PATCH] ASoC: SOF: ensure all fields in header are zero'd before copying back to userspace
by Colin King 22 Apr '20

22 Apr '20

From: Colin Ian King <colin.king(a)canonical.com> Field header.tlv is uninitialized and being copied back to userspace and hence leaking data from the stack to userspace. Fix this by ensuring the header structure is zero'd. Fixes: c3078f539704 ("ASoC: SOF: Add Sound Open Firmware KControl support") Addresses-Coverity: ("Uninitialized scalar variable") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/sof/control.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/control.c b/sound/soc/sof/control.c index dfc412e2d956..97d5c1a4c1ff 100644 --- a/sound/soc/sof/control.c +++ b/sound/soc/sof/control.c @@ -362,7 +362,7 @@ int snd_sof_bytes_ext_get(struct snd_kcontrol *kcontrol, struct snd_sof_control *scontrol = be->dobj.private; struct snd_soc_component *scomp = scontrol->scomp; struct sof_ipc_ctrl_data *cdata = scontrol->control_data; - struct snd_ctl_tlv header; + struct snd_ctl_tlv header = { }; struct snd_ctl_tlv __user *tlvd = (struct snd_ctl_tlv __user *)binary_data; int data_size; -- 2.25.1

3 2

[Sound-open-firmware] What is the role of dma_status function?
by Daniel Baluta 21 Apr '20

21 Apr '20

I see that all DMA drivers fill in this .status function, but I couldn't find any users of it. Any idea?

2 3

[Sound-open-firmware] SOF in a laptop Whiskey Lake ALC215
by josep lladonosa capell 20 Apr '20

20 Apr '20

Hello, This is my first time here. I contact you because I am trying to make microphones from my laptop work under Debian 10.3 (additional compiled kernel 5.6.4 but tried with your Linux kernel 5.6.0-rc7+). Laptop is an HP Elitebook 830 G6. $ sudo lspci -s 0:1f.3 -nnnnv 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 11) Subsystem: Hewlett-Packard Company Cannon Point-LP High Definition Audio Controller [103c:854a] Flags: bus master, fast devsel, latency 64, IRQ 158 Memory at 4022108000 (64-bit, non-prefetchable) [size=16K] Memory at 4022000000 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [80] Vendor Specific Information: Len=14 <?> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ I followed your instructions to build firmware and linux kernel (in a separate machine - just Cannon Lake and then installing firmware+kernel). This is part of dmesg: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [ 4.460258] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 4.460428] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver ... [ 4.530541] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 4.530676] sof-audio-pci 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 4.530768] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [ 4.533271] sof-audio-pci 0000:00:1f.3: use msi interrupt mode ... [ 4.537726] sof-audio-pci 0000:00:1f.3: warning: No matching ASoC machine driver found [ 4.537727] sof-audio-pci 0000:00:1f.3: error: no matching ASoC machine driver found - aborting probe [ 4.537729] sof-audio-pci 0000:00:1f.3: error: failed to get machine info -19 [ 4.537835] sof-audio-pci 0000:00:1f.3: error: failed to probe DSP hardware! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Result is (from alsa-info): !!Soundcards recognised by ALSA !!----------------------------- --- no soundcards --- !!PCI Soundcards installed in the system !!-------------------------------------- 00:1f.3 Multimedia audio controller: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 11) In next email I will attach related debug information (/sys/kernel/debug/dynamic_debug/control lines related to sound.

2 9

[Sound-open-firmware] [PATCH AUTOSEL 5.4 68/78] ASoC: SOF: trace: fix unconditional free in trace release
by Sasha Levin 18 Apr '20

18 Apr '20

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit e6110114d18d330c05fd6de9f31283fd086a5a3a ] Check if DMA pages were successfully allocated in initialization before calling free. For many types of memory (like sgbufs) the extra free is harmless, but not all backends track allocation state, so add an explicit check. Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200124213625.30186-5-pierre-louis.bossart@linux… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/trace.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index 4c3cff031fd66..fd6f5913782bf 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -328,7 +328,10 @@ void snd_sof_free_trace(struct snd_sof_dev *sdev) { snd_sof_release_trace(sdev); - snd_dma_free_pages(&sdev->dmatb); - snd_dma_free_pages(&sdev->dmatp); + if (sdev->dma_trace_pages) { + snd_dma_free_pages(&sdev->dmatb); + snd_dma_free_pages(&sdev->dmatp); + sdev->dma_trace_pages = 0; + } } EXPORT_SYMBOL(snd_sof_free_trace); -- 2.20.1

1 0

[Sound-open-firmware] [PATCH AUTOSEL 5.5 70/75] ASoC: SOF: trace: fix unconditional free in trace release
by Sasha Levin 18 Apr '20

18 Apr '20

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit e6110114d18d330c05fd6de9f31283fd086a5a3a ] Check if DMA pages were successfully allocated in initialization before calling free. For many types of memory (like sgbufs) the extra free is harmless, but not all backends track allocation state, so add an explicit check. Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200124213625.30186-5-pierre-louis.bossart@linux… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/trace.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index b0e4556c8536a..5bf63fa67fb09 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -343,7 +343,10 @@ void snd_sof_free_trace(struct snd_sof_dev *sdev) snd_sof_release_trace(sdev); - snd_dma_free_pages(&sdev->dmatb); - snd_dma_free_pages(&sdev->dmatp); + if (sdev->dma_trace_pages) { + snd_dma_free_pages(&sdev->dmatb); + snd_dma_free_pages(&sdev->dmatp); + sdev->dma_trace_pages = 0; + } } EXPORT_SYMBOL(snd_sof_free_trace); -- 2.20.1

1 0

[Sound-open-firmware] First caller of pipeline_copy
by Daniel Baluta 15 Apr '20

15 Apr '20

Hi, I want to understand how copying data works on a playback pipeline, specifically how the first bytes are copied. It looks like SOF_SCHEDULE_LL_DMA scheduler takes care about scheduling pipeline_task. In a simple pipeline with Host <-> (buf0) <-> Volume <->(buf1) DAI the data needs to be propagated from upstream up to DAI. DMA is responsible to copy the data from buf1 to DAI. But at the time the DMA interrupt arrives the data are not yet propagated to buf1. We would need a way to preload first bytes. But I couldn't find anywhere in the code where this happens.

3 4

Re: [Sound-open-firmware] [thesofproject/sof] Pre-release v1.5-rc1 - v1.5-rc1
by Daniel Baluta 09 Apr '20

09 Apr '20

Thanks Liam for tagging the release. We are still working on late SDMA bugs hope we can catch this release. Other than that we will update for furter v1.5 stable releases (e.g v1.5.1, v1.5.2 etc). When is your plan to do the official release? Maybe at least wait till Monday. Also, I wonder if it makes sense to create our on v1.5-imx branch. Daniel. On Thu, Apr 9, 2020 at 11:38 AM Liam Girdwood <notifications(a)github.com> wrote: > v1.5-rc1 <https://github.com/thesofproject/sof/releases/tag/v1.5-rc1> > > Repository: thesofproject/sof <https://github.com/thesofproject/sof> · > Tag: v1.5-rc1 <https://github.com/thesofproject/sof/tree/v1.5-rc1> · > Commit: 5f7d4e2 > <https://github.com/thesofproject/sof/commit/5f7d4e268f75071b9f3cba0a5321822…> > · Released by: lgirdwood <https://github.com/lgirdwood> > > 1st release candidate for v1.5. CI is mostly good so hopefully short time > until we can tag v1.5 if validation approves. > Details to follow. > — > > This release has 2 assets: > > - Source code (zip) > - Source code (tar.gz) > > Visit the release page > <https://github.com/thesofproject/sof/releases/tag/v1.5-rc1> to download > them. > > — > You are receiving this because you are watching this repository. > View it on GitHub > <https://github.com/thesofproject/sof/releases/tag/v1.5-rc1> or > unsubscribe > <https://github.com/thesofproject/sof/unsubscribe_via_email/AAAPG3A2NFRNYZS2…> > from all notifications for this repository. >

2 2

Re: [Sound-open-firmware] [PATCH v2 00/12] [RESEND] ASoC: SOF DSP virtualisation
by Guennadi Liakhovetski 07 Apr '20

07 Apr '20

Hi Mark, On Tue, Apr 07, 2020 at 12:30:26PM +0100, Mark Brown wrote: > On Tue, Apr 07, 2020 at 01:24:11PM +0200, Guennadi Liakhovetski wrote: > > > After a discussion we agreed, that we shall try to port SOF VirtIO support on > > top of RPMSG, even though this would be the first ever such use of RPMSG. And > > since this likely will take a while and be a big change we suspend this > > review process for now. > > OK... the generic patches (IIRC it was about the list that Liam > identified) looked OK so if you want to send them by themselves then I > can apply them and it's less diff for you to carry. Ok, I'll route them via Pierre then, because they include a new SOF IPC, which probably requires an ABI version update, even though it will never be sent to the DSP. Thanks Guennadi

1 0

Re: [Sound-open-firmware] [PATCH v2 00/12] [RESEND] ASoC: SOF DSP virtualisation
by Guennadi Liakhovetski 07 Apr '20

07 Apr '20

Hi Mark, On Fri, Apr 03, 2020 at 10:28:42AM +0100, Mark Brown wrote: > On Fri, Apr 03, 2020 at 11:13:54AM +0200, Guennadi Liakhovetski wrote: > > 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 > > I've asked a couple of times for documentation of the protocol here but > don't think I've seen anything yet? Sorry, we were thinking about the best way to reply. I think Liam will provide more procise information. The API we are using is the same as what is already used by SOF to communicate with the DSP firmware. With VirtIO we re-use the same IPC messages as those, used with the DSP, they are just transmitted over Virtual Queues. Additionally to existing IPC messages the SOF VirtIO implementation defines 3 more message types for topology loading and DSP power management. IPC message types are defined in include/sound/sof/header.h, IPC overview is available in https://thesofproject.github.io/latest/developer_guides/linux_driver/archit… but I'm not aware of a formal SOF IPC protocol documentation. Thanks Guennadi

2 3

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

03 Apr '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]. I'd like to have at least a tentative approval on this series to send vhost patches 3 and 9 to virtualisation lists / maintainers for review and eventual merging. 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 | 13 +- 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 | 52 ++ sound/soc/sof/topology.c | 71 ++- sound/soc/sof/vhost-be.c | 1248 ++++++++++++++++++++++++++++++++++++++ sound/soc/sof/virtio-fe.c | 922 ++++++++++++++++++++++++++++ 29 files changed, 3552 insertions(+), 108 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