Sound-open-firmware February 2023

sound-open-firmware@alsa-project.org

10 participants
7 discussions

[Sound-open-firmware] Re: [PATCH][next] ASoC: SOF: ipc4-topology: Replace fake flexible arrays with flexible-array member
by Péter Ujfalusi 24 Feb '23

24 Feb '23

On 24/02/2023 05:42, Gustavo A. R. Silva wrote: > Zero-length arrays as fake flexible arrays are deprecated and we are > moving towards adopting C99 flexible-array members, instead. > > Use the DECLARE_FLEX_ARRAY() helper macro to transform zero-length > arrays in unions with flexible-array members. > > Address the following warnings found with GCC-13 and > -fstrict-flex-arrays=3 enabled: > sound/soc/sof/ipc4-control.c:176:77: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:78:29: warning: array subscript 0 is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:80:33: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:95:53: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:96:53: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:93:53: warning: array subscript 0 is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:140:58: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:141:29: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-control.c:142:29: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-topology.c:1475:36: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > sound/soc/sof/ipc4-topology.c:1476:36: warning: array subscript i is outside array bounds of ‘struct sof_ipc4_ctrl_value_chan[0]’ [-Warray-bounds=] > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> > > Link: https://github.com/KSPP/linux/issues/21 > Link: https://github.com/KSPP/linux/issues/193 > Link: https://github.com/KSPP/linux/issues/258 > Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] > Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> > --- > sound/soc/sof/ipc4-topology.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/sof/ipc4-topology.h b/sound/soc/sof/ipc4-topology.h > index 72529179ac22..8507171a6e4d 100644 > --- a/sound/soc/sof/ipc4-topology.h > +++ b/sound/soc/sof/ipc4-topology.h > @@ -266,8 +266,8 @@ struct sof_ipc4_control_data { > int index; > > union { > - struct sof_ipc4_ctrl_value_chan chanv[0]; > - struct sof_abi_hdr data[0]; > + DECLARE_FLEX_ARRAY(struct sof_ipc4_ctrl_value_chan, chanv); > + DECLARE_FLEX_ARRAY(struct sof_abi_hdr, data); > }; > }; > -- Péter

1 0

[Sound-open-firmware] sound-open-firmware mailing list - mailman upgrade
by Jaroslav Kysela 21 Feb '23

21 Feb '23

Hi all, I upgraded the mailman 2 to mailman 3 on the ALSA server. I hope that you do not see any differences, but there is a major change in the handling of the user logins to maintain your subscription using the web interface [1]. It means that you should create a new user account on the mailman server [2]. Do not request the password change for the first login. Although the subscriptions are migrated, the new system will send you a reply that your e-mail is not in the user database. Although it is technically correct, it is very confusing. Create a new account using identical e-mail as you are subscribed. Your subscription will be assigned to this account according your e-mail. You will be allowed to maintain all list subscriptions on the server then (not only one list subscription like before). Archive URLs are different, but I will keep the old archive (URLs), too. Enjoy new Postorius and HyperKitty frontends. If you have any issue, please, let me know. Thanks, Jaroslav [1] https://docs.mailman3.org/en/latest/faq-migration.html [2] https://mailman.alsa-project.org -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

1 0

[Sound-open-firmware] [PATCH AUTOSEL 6.1 16/24] ASoC: SOF: amd: Fix for handling spurious interrupts from DSP
by Sasha Levin 15 Feb '23

15 Feb '23

From: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> [ Upstream commit 2e7c6652f9b86c01cbd4e988057a746a3a461969 ] As interrupts are Level-triggered,unless and until we deassert the register the interrupts are generated which causes spurious interrupts unhandled. Now we deasserted the interrupt at top half which solved the below "nobody cared" warning. warning reported in dmesg: irq 80: nobody cared (try booting with the "irqpoll" option) CPU: 5 PID: 2735 Comm: irq/80-AudioDSP Not tainted 5.15.86-15817-g4c19f3e06d49 #1 1bd3fd932cf58caacc95b0504d6ea1e3eab22289 Hardware name: Google Skyrim/Skyrim, BIOS Google_Skyrim.15303.0.0 01/03/2023 Call Trace: <IRQ> dump_stack_lvl+0x69/0x97 __report_bad_irq+0x3a/0xae note_interrupt+0x1a9/0x1e3 handle_irq_event_percpu+0x4b/0x6e handle_irq_event+0x36/0x5b handle_fasteoi_irq+0xae/0x171 __common_interrupt+0x48/0xc4 </IRQ> handlers: acp_irq_handler [snd_sof_amd_acp] threaded [<000000007e089f34>] acp_irq_thread [snd_sof_amd_acp] Disabling IRQ #80 Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> Link: https://lore.kernel.org/r/20230203123254.1898794-1-Vsujithkumar.Reddy@amd.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp.c | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 36966643e36ab..8afd67ba1e5a3 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -316,7 +316,6 @@ static irqreturn_t acp_irq_thread(int irq, void *context) { struct snd_sof_dev *sdev = context; const struct sof_amd_acp_desc *desc = get_chip_info(sdev->pdata); - unsigned int base = desc->dsp_intr_base; unsigned int val, count = ACP_HW_SEM_RETRY_COUNT; val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->ext_intr_stat); @@ -326,28 +325,20 @@ static irqreturn_t acp_irq_thread(int irq, void *context) return IRQ_HANDLED; } - val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET); - if (val & ACP_DSP_TO_HOST_IRQ) { - while (snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset)) { - /* Wait until acquired HW Semaphore lock or timeout */ - count--; - if (!count) { - dev_err(sdev->dev, "%s: Failed to acquire HW lock\n", __func__); - return IRQ_NONE; - } + while (snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset)) { + /* Wait until acquired HW Semaphore lock or timeout */ + count--; + if (!count) { + dev_err(sdev->dev, "%s: Failed to acquire HW lock\n", __func__); + return IRQ_NONE; } - - sof_ops(sdev)->irq_thread(irq, sdev); - val |= ACP_DSP_TO_HOST_IRQ; - snd_sof_dsp_write(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET, val); - - /* Unlock or Release HW Semaphore */ - snd_sof_dsp_write(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset, 0x0); - - return IRQ_HANDLED; } - return IRQ_NONE; + sof_ops(sdev)->irq_thread(irq, sdev); + /* Unlock or Release HW Semaphore */ + snd_sof_dsp_write(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset, 0x0); + + return IRQ_HANDLED; }; static irqreturn_t acp_irq_handler(int irq, void *dev_id) @@ -358,8 +349,11 @@ static irqreturn_t acp_irq_handler(int irq, void *dev_id) unsigned int val; val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET); - if (val) + if (val) { + val |= ACP_DSP_TO_HOST_IRQ; + snd_sof_dsp_write(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET, val); return IRQ_WAKE_THREAD; + } return IRQ_NONE; } -- 2.39.0

1 0

Re: [Sound-open-firmware] Real hardware (boards) on which the SOF runs
by Pierre-Louis Bossart 13 Feb '23

13 Feb '23

On 1/31/23 04:26, Gerion Entrup wrote: > Hi Pierre, > > Am Montag, 30. Januar 2023, 15:55:47 CET schrieb Pierre-Louis Bossart: >> Hi Gerion, >> >> Zephyr support is still very new, if you want to start using it now it >> has to be clear that you'll have to follow the bleeding edge firmware >> development on TigerLake+ devices. All previous platforms will not have >> Zephyr support and have been parked on a long-term XTOS-based support >> branch. > That is good to know. > > >> The only Intel-based devices you can use for you own development are the >> Up Extreme i11 boards or TigerLake+ Chromebooks in developer mode. These >> two sets of devices use the community key and have the DSP configured. > The Extreme i11 boards look promising. > Regarding the Chrombooks: I'm not familiar with these devices. Is it > possible to use them as a "server"? So reboot and connect to them over SSH > while the developer mode stays active? yes, the 'developer mode' is something that you can set once and it can remain on over reboot cycles. It's not that straightforward but it's not the end of the world either. see here two examples of Chromebooks used for SOF CI with a Ubuntu setup and kernel/firmware updated for tests run over SSH. https://sof-ci.01.org/linuxpr/PR4163/build2911/devicetest/index.html?model=… https://sof-ci.01.org/linuxpr/PR4163/build2911/devicetest/index.html?model=… Note that our default test setup relies on a minimal kernel configuration based on 'make defconfig' + scripts to add what we need, see https://github.com/thesofproject/kconfig/blob/master/kconfig-sof-default.sh This may need to be improved with your own configurations depending on what you want to test. Hope this helps. -Pierre

4 3

[Sound-open-firmware] [PATCH AUTOSEL 6.1 02/38] ASoC: SOF: sof-audio: start with the right widget type
by Sasha Levin 09 Feb '23

09 Feb '23

From: Bard Liao <yung-chuan.liao(a)linux.intel.com> [ Upstream commit fcc4348adafe53928fda46d104c1798e5a4de4ff ] If there is a connection between a playback stream and a capture stream, all widgets that are connected to the playback stream and the capture stream will be in the list. So, we have to start with the exactly right widget type. snd_soc_dapm_aif_out is for capture stream and a playback stream should start with a snd_soc_dapm_aif_in widget. Contrarily, snd_soc_dapm_dai_in is for playback stream, and a capture stream should start with a snd_soc_dapm_dai_out widget. Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20230117123534.2075-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/sof-audio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/sof-audio.c b/sound/soc/sof/sof-audio.c index 62092e2d609c7..bb92d8c8fbce6 100644 --- a/sound/soc/sof/sof-audio.c +++ b/sound/soc/sof/sof-audio.c @@ -429,11 +429,11 @@ sof_walk_widgets_in_order(struct snd_sof_dev *sdev, struct snd_soc_dapm_widget_l for_each_dapm_widgets(list, i, widget) { /* starting widget for playback is AIF type */ - if (dir == SNDRV_PCM_STREAM_PLAYBACK && !WIDGET_IS_AIF(widget->id)) + if (dir == SNDRV_PCM_STREAM_PLAYBACK && widget->id != snd_soc_dapm_aif_in) continue; /* starting widget for capture is DAI type */ - if (dir == SNDRV_PCM_STREAM_CAPTURE && !WIDGET_IS_DAI(widget->id)) + if (dir == SNDRV_PCM_STREAM_CAPTURE && widget->id != snd_soc_dapm_dai_out) continue; switch (op) { -- 2.39.0

1 0

[Sound-open-firmware] [PATCH] ASoC: SOF: fix intel-soundwire link failure
by Arnd Bergmann 03 Feb '23

03 Feb '23

From: Arnd Bergmann <arnd(a)arndb.de> My randconfig build setup ran into a rare build failure with CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE=y CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE=m CONFIG_SOUNDWIRE=y CONFIG_SOUNDWIRE_INTEL=m CONFIG_SND_SOC_SOF_HDA=y CONFIG_SND_SOC_SOF_INTEL_TGL=y x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_init_caps': hda.c:(.text+0x691): undefined reference to `sdw_intel_cnl_hw_ops' x86_64-linux-ld: hda.c:(.text+0x6f2): undefined reference to `sdw_intel_probe' x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_sdw_startup': hda.c:(.text+0x1c40): undefined reference to `sdw_intel_startup' x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_sdw_process_wakeen': hda.c:(.text+0x1cb6): undefined reference to `sdw_intel_process_wakeen_event' x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_dsp_interrupt_thread': hda.c:(.text+0x1d67): undefined reference to `sdw_intel_thread' x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_dsp_remove': hda.c:(.text+0x2655): undefined reference to `sdw_intel_exit' My best understanding is that the definition of SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE was intended to avoid this problem, but got it wrong for the SND_SOC_SOF_INTEL_SOUNDWIRE=m case, where the 'select' is meant to set SOUNDWIRE_INTEL to the value of SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE rather than the intersection of SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE and SND_SOC_SOF_INTEL_SOUNDWIRE. Change the condition to check for SND_SOC_SOF_INTEL_SOUNDWIRE to be a boolean rather than a tristate expression in order to propagate this as intended. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- I could not figure out if this is a recent regression or if the problem has existed for a long time and is just really hard to trigger. I first saw it on linux-next-20230201. --- sound/soc/sof/intel/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index 36a0e2bf30ff..715ba8a7f2f8 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -322,8 +322,8 @@ config SND_SOC_SOF_HDA_PROBES config SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE tristate - select SOUNDWIRE_INTEL if SND_SOC_SOF_INTEL_SOUNDWIRE - select SND_INTEL_SOUNDWIRE_ACPI if SND_SOC_SOF_INTEL_SOUNDWIRE + select SOUNDWIRE_INTEL if SND_SOC_SOF_INTEL_SOUNDWIRE != n + select SND_INTEL_SOUNDWIRE_ACPI if SND_SOC_SOF_INTEL_SOUNDWIRE != n config SND_SOC_SOF_INTEL_SOUNDWIRE tristate "SOF support for SoundWire" -- 2.39.0

3 2

[Sound-open-firmware] [PATCH] ASoC: SOF: amd: Fix for handling spurious interrupts from DSP
by V sujith kumar Reddy 02 Feb '23

02 Feb '23

As interrupts are Level-triggered,unless and until we deassert the register the interrupts are generated which causes spurious interrupts unhandled. Now we deasserted the interrupt at top half which solved the below "nobody cared" warning. warning reported in dmesg: irq 80: nobody cared (try booting with the "irqpoll" option) CPU: 5 PID: 2735 Comm: irq/80-AudioDSP Not tainted 5.15.86-15817-g4c19f3e06d49 #1 1bd3fd932cf58caacc95b0504d6ea1e3eab22289 Hardware name: Google Skyrim/Skyrim, BIOS Google_Skyrim.15303.0.0 01/03/2023 Call Trace: <IRQ> dump_stack_lvl+0x69/0x97 __report_bad_irq+0x3a/0xae note_interrupt+0x1a9/0x1e3 handle_irq_event_percpu+0x4b/0x6e handle_irq_event+0x36/0x5b handle_fasteoi_irq+0xae/0x171 __common_interrupt+0x48/0xc4 </IRQ> handlers: acp_irq_handler [snd_sof_amd_acp] threaded [<000000007e089f34>] acp_irq_thread [snd_sof_amd_acp] Disabling IRQ #80 Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> --- sound/soc/sof/amd/acp.c | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 6bd2888fbb66..d5ccd4d09278 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -318,7 +318,6 @@ static irqreturn_t acp_irq_thread(int irq, void *context) { struct snd_sof_dev *sdev = context; const struct sof_amd_acp_desc *desc = get_chip_info(sdev->pdata); - unsigned int base = desc->dsp_intr_base; unsigned int val, count = ACP_HW_SEM_RETRY_COUNT; val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->ext_intr_stat); @@ -328,28 +327,20 @@ static irqreturn_t acp_irq_thread(int irq, void *context) return IRQ_HANDLED; } - val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET); - if (val & ACP_DSP_TO_HOST_IRQ) { - while (snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset)) { - /* Wait until acquired HW Semaphore lock or timeout */ - count--; - if (!count) { - dev_err(sdev->dev, "%s: Failed to acquire HW lock\n", __func__); - return IRQ_NONE; - } + while (snd_sof_dsp_read(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset)) { + /* Wait until acquired HW Semaphore lock or timeout */ + count--; + if (!count) { + dev_err(sdev->dev, "%s: Failed to acquire HW lock\n", __func__); + return IRQ_NONE; } - - sof_ops(sdev)->irq_thread(irq, sdev); - val |= ACP_DSP_TO_HOST_IRQ; - snd_sof_dsp_write(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET, val); - - /* Unlock or Release HW Semaphore */ - snd_sof_dsp_write(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset, 0x0); - - return IRQ_HANDLED; } - return IRQ_NONE; + sof_ops(sdev)->irq_thread(irq, sdev); + /* Unlock or Release HW Semaphore */ + snd_sof_dsp_write(sdev, ACP_DSP_BAR, desc->hw_semaphore_offset, 0x0); + + return IRQ_HANDLED; }; static irqreturn_t acp_irq_handler(int irq, void *dev_id) @@ -360,8 +351,11 @@ static irqreturn_t acp_irq_handler(int irq, void *dev_id) unsigned int val; val = snd_sof_dsp_read(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET); - if (val) + if (val) { + val |= ACP_DSP_TO_HOST_IRQ; + snd_sof_dsp_write(sdev, ACP_DSP_BAR, base + DSP_SW_INTR_STAT_OFFSET, val); return IRQ_WAKE_THREAD; + } return IRQ_NONE; } -- 2.25.1

2 1

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware February 2023