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

[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

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

30 Jan '23

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. 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. If you want to get access to the Cadence Tensilica compiler, things get complicated as well. Usually this requires an NDA. That means you may need to use GCC with a lower performance to be expected since HiFi3 instructions are not supported by GCC just yet. We should add this information in the 'Getting started' documentation. Hope this helps, -Pierre On 1/30/23 08:22, sound-open-firmware-owner(a)alsa-project.org wrote: > ForwardedMessage.eml > > Subject: > Real hardware (boards) on which the SOF runs > From: > Gerion Entrup <entrup(a)sra.uni-hannover.de> > Date: > 1/30/23, 08:22 > > To: > sound-open-firmware(a)alsa-project.org > > > Hi, > > we are doing operating systems research and think that the SOF is of > great value because of its usage of Zephyr. > > We therefore wanted to get some real hardware where SOF is running on. > However, that it kind of complicated. > We know of some Thinkpads (Intel 12th gen) that are running the SOF. > However, we also have access to another Intel 12th gen desktop PC on > which the vendor seems to have disabled the Intel DSP forever (at least > there is not setting in the BIOS/UEFI). > > Online, we only found the Minnowboard Turbot as a board that has an SOF > enabled DSP. However, the board seems to be discontinued so we cannot > buy it. > > Do you know of some (preferable low budget) boards on which the SOF runs? > Is there some kind of hardware matrix for whole PCs (laptops, single > board PCs) that are supported by the SOF? On the website, I have only > found a list of CPU platforms [1]. > > Best, > Gerion > > > [1] https://thesofproject.github.io/latest/platforms/index.html

1 0

[Sound-open-firmware] [linux-next:master] BUILD REGRESSION d514392f17fd4d386cfadde7f849d97db4ca1fb0
by kernel test robot 20 Jan '23

20 Jan '23

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: d514392f17fd4d386cfadde7f849d97db4ca1fb0 Add linux-next specific files for 20230120 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301191616.R33Dvxk4-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202301192229.wL7iPJxS-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202301201120.aIaz7dT4-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202301202042.herfGxx6-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/virt/kvm/api.rst:5070: WARNING: Unexpected indentation. drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5253:24: sparse: left side has type restricted __le16 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5253:24: sparse: right side has type restricted __le32 idma64.c:(.text+0x6a): undefined reference to `devm_platform_ioremap_resource' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/net/dsa/microchip/ksz_ptp.c:217 ksz_ptp_clock_register() warn: passing zero to 'PTR_ERR' drivers/nvmem/imx-ocotp.c:599:21: sparse: sparse: symbol 'imx_ocotp_layout' was not declared. Should it be static? drivers/nvmem/layouts/sl28vpd.c:143:21: sparse: sparse: symbol 'sl28vpd_layout' was not declared. Should it be static? mm/hugetlb.c:3101 alloc_hugetlb_folio() error: uninitialized symbol 'h_cg'. mm/zsmalloc.c:900:20: warning: unused function 'obj_allocated' [-Wunused-function] sound/soc/sof/sof-audio.c:329 sof_prepare_widgets_in_path() error: we previously assumed 'swidget' could be null (see line 306) Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- arc-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- arm-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- arm-randconfig-s032-20230119 | `-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static |-- arm64-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- csky-randconfig-m041-20230119 | |-- drivers-net-dsa-microchip-ksz_ptp.c-ksz_ptp_clock_register()-warn:passing-zero-to-PTR_ERR | `-- sound-soc-sof-sof-audio.c-sof_prepare_widgets_in_path()-error:we-previously-assumed-swidget-could-be-null-(see-line-) |-- csky-randconfig-r025-20230119 | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- csky-randconfig-s043-20230119 | |-- drivers-net-wireless-realtek-rtl8xxxu-rtl8xxxu_core.c:sparse:left-side-has-type-restricted-__le16 | |-- drivers-net-wireless-realtek-rtl8xxxu-rtl8xxxu_core.c:sparse:right-side-has-type-restricted-__le32 | `-- drivers-net-wireless-realtek-rtl8xxxu-rtl8xxxu_core.c:sparse:sparse:invalid-assignment: |-- i386-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- ia64-allmodconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- ia64-randconfig-c033-20230119 | `-- drivers-net-ethernet-microchip-vcap-vcap_api.c:WARNING-opportunity-for-kmemdup |-- ia64-randconfig-s052-20230119 | `-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static |-- loongarch-randconfig-r024-20230119 | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- loongarch-randconfig-s042-20230119 | `-- drivers-nvmem-layouts-sl28vpd.c:sparse:sparse:symbol-sl28vpd_layout-was-not-declared.-Should-it-be-static |-- m68k-randconfig-c004-20230119 | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- mips-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- openrisc-randconfig-s033-20230119 | `-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static |-- powerpc-allmodconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- riscv-randconfig-s041-20230119 | `-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static |-- s390-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- sparc-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used |-- x86_64-allnoconfig | `-- Documentation-virt-kvm-api.rst:WARNING:Unexpected-indentation. |-- x86_64-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_dp_training.c:warning:variable-result-set-but-not-used `-- x86_64-randconfig-m001 clang_recent_errors |-- s390-randconfig-r044-20230119 | `-- idma64.c:(.text):undefined-reference-to-devm_platform_ioremap_resource `-- x86_64-randconfig-a012 `-- mm-zsmalloc.c:warning:unused-function-obj_allocated elapsed time: 882m configs tested: 79 configs skipped: 3 gcc tested configs: x86_64 allnoconfig um i386_defconfig i386 defconfig um x86_64_defconfig x86_64 defconfig x86_64 rhel-8.3 arc defconfig alpha defconfig arm defconfig i386 randconfig-a001 x86_64 rhel-8.3-func m68k allyesconfig x86_64 rhel-8.3-syz x86_64 rhel-8.3-kselftests x86_64 allyesconfig powerpc allnoconfig x86_64 rhel-8.3-kunit ia64 allmodconfig arm randconfig-r046-20230119 x86_64 randconfig-a002 arm allyesconfig arc randconfig-r043-20230119 m68k allmodconfig i386 randconfig-a003 arc allyesconfig arm64 allyesconfig alpha allyesconfig x86_64 rhel-8.3-kvm x86_64 randconfig-a006 i386 randconfig-a005 x86_64 rhel-8.3-bpf x86_64 randconfig-a004 sparc64 alldefconfig riscv allnoconfig sparc sparc32_defconfig m68k hp300_defconfig i386 allyesconfig powerpc mpc85xx_cds_defconfig parisc alldefconfig riscv nommu_virt_defconfig mips bigsur_defconfig arm keystone_defconfig sh secureedge5410_defconfig i386 randconfig-a014 riscv nommu_k210_defconfig s390 defconfig i386 randconfig-a012 x86_64 randconfig-a013 i386 randconfig-a016 riscv rv32_defconfig s390 allmodconfig sh allmodconfig i386 debian-10.3-kselftests x86_64 randconfig-a011 i386 debian-10.3 i386 randconfig-c001 mips allyesconfig x86_64 randconfig-a015 s390 allyesconfig powerpc allmodconfig clang tested configs: x86_64 rhel-8.3-rust x86_64 randconfig-a005 hexagon randconfig-r045-20230119 x86_64 randconfig-a001 i386 randconfig-a002 riscv randconfig-r042-20230119 x86_64 randconfig-a003 hexagon randconfig-r041-20230119 s390 randconfig-r044-20230119 i386 randconfig-a006 x86_64 randconfig-k001 i386 randconfig-a004 arm omap1_defconfig i386 randconfig-a013 i386 randconfig-a011 i386 randconfig-a015 x86_64 randconfig-a016 x86_64 randconfig-a012 x86_64 randconfig-a014 -- 0-DAY CI Kernel Test Service https://01.org/lkp

1 0

Re: [Sound-open-firmware] [PATCH] ASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write()
by Mark Brown 20 Jan '23

20 Jan '23

On Thu, 19 Jan 2023 17:58:54 +0300, Dan Carpenter wrote: > The "id" comes from the user. Change the type to unsigned to prevent > an array underflow. > > Applied to broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write() commit: ea57680af47587397f5005d7758022441ed66d54 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0