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

[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

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