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

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware April 2020