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

[Sound-open-firmware] [PATCH v2 0/2] soundwire: remove multiple superfluous "else" statements
by Guennadi Liakhovetski 11 May '20

11 May '20

Two patches cleaning up the same issue for soundwire core and Intel- specific code. v2: split into 2 for core and Intel code Guennadi Liakhovetski (2): soundwire: (cosmetic) remove multiple superfluous "else" statements soundwire: intel: (cosmetic) remove multiple superfluous "else" statements drivers/soundwire/bus.c | 17 ++++++++++------- drivers/soundwire/cadence_master.c | 8 ++++++-- drivers/soundwire/intel_init.c | 4 +++- 3 files changed, 19 insertions(+), 10 deletions(-) -- 1.9.3

2 3

[Sound-open-firmware] [PATCH -next] ASoC: SOF: Intel: Mark cht_debugfs as __maybe_unused
by YueHaibing 08 May '20

08 May '20

When CONFIG_SND_SOC_SOF_BAYTRAIL is not set, gcc warns: sound/soc/sof/intel/byt.c:85:41: warning: ‘cht_debugfs’ defined but not used [-Wunused-const-variable=] static const struct snd_sof_debugfs_map cht_debugfs[] = { ^~~~~~~~~~~ Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- sound/soc/sof/intel/byt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/byt.c b/sound/soc/sof/intel/byt.c index f872bb1f2682..1c75e4220e9d 100644 --- a/sound/soc/sof/intel/byt.c +++ b/sound/soc/sof/intel/byt.c @@ -82,7 +82,7 @@ static const struct snd_sof_debugfs_map byt_debugfs[] = { SOF_DEBUGFS_ACCESS_ALWAYS}, }; -static const struct snd_sof_debugfs_map cht_debugfs[] = { +static const struct snd_sof_debugfs_map __maybe_unused cht_debugfs[] = { {"dmac0", BYT_DSP_BAR, DMAC0_OFFSET, DMAC_SIZE, SOF_DEBUGFS_ACCESS_ALWAYS}, {"dmac1", BYT_DSP_BAR, DMAC1_OFFSET, DMAC_SIZE, -- 2.17.1

4 4

[Sound-open-firmware] [PATCH] ASoC: SOF: Replace zero-length array with flexible-array
by Gustavo A. R. Silva 07 May '20

07 May '20

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> --- sound/soc/sof/probe.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/probe.h b/sound/soc/sof/probe.h index 45daa5552834..250c4817f637 100644 --- a/sound/soc/sof/probe.h +++ b/sound/soc/sof/probe.h @@ -36,7 +36,7 @@ struct sof_probe_point_desc { struct sof_ipc_probe_dma_add_params { struct sof_ipc_cmd_hdr hdr; unsigned int num_elems; - struct sof_probe_dma dma[0]; + struct sof_probe_dma dma[]; } __packed; struct sof_ipc_probe_info_params { @@ -51,19 +51,19 @@ struct sof_ipc_probe_info_params { struct sof_ipc_probe_dma_remove_params { struct sof_ipc_cmd_hdr hdr; unsigned int num_elems; - unsigned int stream_tag[0]; + unsigned int stream_tag[]; } __packed; struct sof_ipc_probe_point_add_params { struct sof_ipc_cmd_hdr hdr; unsigned int num_elems; - struct sof_probe_point_desc desc[0]; + struct sof_probe_point_desc desc[]; } __packed; struct sof_ipc_probe_point_remove_params { struct sof_ipc_cmd_hdr hdr; unsigned int num_elems; - unsigned int buffer_id[0]; + unsigned int buffer_id[]; } __packed; int sof_ipc_probe_init(struct snd_sof_dev *sdev,

1 0

Re: [Sound-open-firmware] 回复: 回复: 回复: SOF documentation
by Daniel Baluta 06 May '20

06 May '20

On 5/6/20 2:26 PM, Terry Lv wrote: > Hi Daniel, > > I make a graph for my audio demo, could you help to review it? > My aim is to make a demo with two PCMs: > > 1. Warning sound. > 2. Streaming music (using equalizer widget). > 3. Multiplexer for both PCMs with volumn control. Priority of warning > sound is higher than music. > > My drafted graph is: > > PCM0 ----> volume ----------------+ > |--low latency mixer ----> volume ----> SSP(WMA8960) > PCM1 ----> volume ----> SRC ----+ > > Also, I've some questions. > > 1. Is it enough to use priority in PIPELINE_PCM_ADD to reduce music > volume when warning sound is ON? > 2. Only mixer is used here. Is multiplexer needed here? > Hi Terry, 1) I'm not sure about this one so adding SOF mailing list. 2) I don't think you need a multiplexer. Also, I think instead of SSP(wma8960) you want SAI(wm8960), right? Also, why do you need SRC component? thanks, Daniel.

1 0

[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