aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/sound/soc/sof (follow)
AgeCommit message (Collapse)AuthorFilesLines
2024-02-21ASoC: Intel: avs: Fixes and new platforms supportMark Brown7-58/+97
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>: The avs-driver continues to be utilized on more recent Intel machines. As TGL-based (cAVS 2.5) e.g.: RPL, inherit most of the functionality from previous platforms: SKL <- APL <- CNL <- ICL <- TGL rather than putting everything into a single file, the platform-specific bits are split into cnl/icl/tgl.c files instead. Makes the division clear and code easier to maintain. Layout of the patchset: First are two changes combined together address the sound-clipping problem, present when only one stream is running - specifically one CAPTURE stream. Follow up is naming-scheme adjustment for some of the existing functions what improves code incohesiveness. As existing IPC/IRQ code operates solely on cAVS 1.5 architecture, it needs no abstraction. The situation changes when newer platforms come into the picture. Thus the next two patches abstract the existing IPC/IRQ handlers so that majority of the common code can be re-used. The ICCMAX change stands out a bit - the AudioDSP firmware loading procedure differs on ICL-based platforms (and onwards) and having a separate commit makes the situation clear to the developers who are going to support the solution from LTS perspective. For that reason I decided not to merge it into the commit introducing the icl.c file.
2024-02-19ASoC: SOF: amd: fix soundwire dependenciesArnd Bergmann1-3/+3
The soundwire-amd driver has a bit of a layering violation requiring the SOF driver to directly call into its exported symbols rather than through an abstraction. The SND_SOC_SOF_AMD_SOUNDWIRE Kconfig symbol tries to deal with the dependency by selecting SOUNDWIRE_AMD in a complicated set of conditions, but gets it wrong for a configuration involving SND_SOC_SOF_AMD_COMMON=y, SND_SOC_SOF_AMD_ACP63=m, and SND_SOC_SOF_AMD_SOUNDWIRE_LINK_BASELINE=m SOUNDWIRE_AMD=m, which results in a link failure: ld.lld: error: undefined symbol: sdw_amd_get_slave_info >>> referenced by acp-common.c ld.lld: error: undefined symbol: amd_sdw_scan_controller ld.lld: error: undefined symbol: sdw_amd_probe ld.lld: error: undefined symbol: sdw_amd_exit >>> referenced by acp.c >>> sound/soc/sof/amd/acp.o:(amd_sof_acp_remove) in archive vmlinux.a In essence, the SND_SOC_SOF_AMD_COMMON option cannot be built-in when trying to link against a modular SOUNDWIRE_AMD driver. Since CONFIG_SOUNDWIRE_AMD is a user-visible option, it really should never be selected by another driver in the first place, so replace the extra complexity with a normal Kconfig dependency in SND_SOC_SOF_AMD_SOUNDWIRE, plus a top-level check that forbids any of the AMD SOF drivers from being built-in with CONFIG_SOUNDWIRE_AMD=m. In normal configs, they should all either be built-in or all loadable modules anyway, so this simplification does not limit any real usecases. Fixes: d948218424bf ("ASoC: SOF: amd: add code for invoking soundwire manager helper functions") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://msgid.link/r/20240219093900.644574-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-14ASoC: SOF: Add some bounds checking to firmware dataDan Carpenter1-0/+2
Smatch complains about "head->full_size - head->header_size" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well. Fixes: d2458baa799f ("ASoC: SOF: ipc3-loader: Implement firmware parsing and loading") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://msgid.link/r/5593d147-058c-4de3-a6f5-540ecb96f6f8@moroto.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-14ASoC: SOF: Extend ChainDMA and DSPless mode to LNL+Mark Brown16-53/+236
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: For both ChainDMA and DSPless mode the requirement is that the link must be serviced by HD-DMA. On pre Lunar Lake platforms this was only valid for HDAudio links but with Lunar Lake all link types now serviced by HD-DMA. This allows us to enable ChainDMA and DSPless mode for SoundWire links as well.
2024-02-13ASoC: SOF: Intel: pci-tgl/lnl: Change default pathsMark Brown2-33/+33
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: Hi, Align the IPC4 firmware path/name and the topology path to the documentation: default_fw_path: intel/sof-ipc4/{platform_name} default_lib_path: intel/sof-ipc4-lib/{platform_name} default_tplg_path: intel/sof-ipc4-tplg default_fw_filename: sof-{platform_name}.ri Tiger Lake and Lunar Lake support is not yet available via the official firmware release, the paths can be changed now to avoid misalignment in the future. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: Intel: pci-tgl: Change the default paths and firmware names ASoC: SOF: Intel: pci-lnl: Change the topology path to intel/sof-ipc4-tplg sound/soc/sof/intel/pci-lnl.c | 2 +- sound/soc/sof/intel/pci-tgl.c | 64 +++++++++++++++++------------------ 2 files changed, 33 insertions(+), 33 deletions(-) -- 2.43.0
2024-02-13ASoC: SOF: ipc4-topology: set config_length based on device_countBard Liao1-1/+5
Set ipc4_copier->data.gtw_cfg.config_length dynamically based on blob->alh_cfg.device_count to align with the other OS. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213123007.29956-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Fix runtime pm usage counter balance after fw exceptionPeter Ujfalusi3-3/+16
If the retain context is enabled we will unconditionally increment the device's pm use count on each exception and when the drivers are unloaded we do not correct this (as we don't know how many times we 'prevented d3 entry'). Introduce a flag to make sure that we do not increment the use count more than once and on module unload decrement the use count if needed to balance it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240213114729.7055-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda-dai: add support for dspless mode beyond HDAudioPierre-Louis Bossart1-1/+10
For SoundWire/ALH, we need to have a dai configured, but we don't want to send a DMA_TLV to firmware. Add additional code branches. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-16-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: lnl: Do not use LNL specific wrappers in DSPless modePeter Ujfalusi1-3/+6
When DSPless mode is selected the DMIC/SSP offload status should not be changed since the DSP is not in use. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-15-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda-dai-ops: add SoundWire dspless modePierre-Louis Bossart1-6/+22
This mode is only supported starting with LunarLake (ACE_2_0). DMIC and SSP remain supported with the DSP only for now, since they need a DAI configuration that is provided to firmware. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-14-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda-dai-ops: use dai_typePierre-Louis Bossart1-2/+1
Now that we have the dai_type we can remove any dependencies on copiers. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-13-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: topology: Parse DAI type token for dspless modeRanjani Sridharan3-0/+14
Starting with LunarLake, the dspless mode can handle SoundWire/ALH, DMIC and SSPs, so we need to identify the dai type from topology. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: start SoundWire links earlier for LNL+ devicesPierre-Louis Bossart3-1/+36
The SoundWire integration is different from previous platforms, with no dependencies on the DSP enablement. We can start the SoundWire links in the probe instead of waiting for the post_fw_run stage. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-11-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: topology: dynamically allocate and store DAI widget->privatePierre-Louis Bossart2-8/+13
For dspless mode, we need to allocate and store an 'sdai' structure. The existing code allocate the data on the stack and does not set the widget->private pointer. This minor change should not have any impact on existing DAIs, even when the DSP is used. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda-dai: remove dspless special casePierre-Louis Bossart1-5/+1
The existing code forces a parameter to be NULL but that parameter is not used yet. Remove the special case in preparation for additional changes. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ipc4-topology: allow chain_dma for all supported DAIsPierre-Louis Bossart1-4/+6
Now that we have a 'is_chain_dma_supported' callback we can use it to double-check possible disconnects between a topology file enabling chain-dma for a DAI and the hardware/firmware capabilities. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ipc4-pcm: fix dma_id for CHAIN_DMA capturePierre-Louis Bossart1-1/+18
The existing code uses (stream_tag - 1) for the host and link dma id. This is correct for playback, but for capture this results in an invalid dma_type being used. The firmware assumes that the dma_id for capture is always larger than DAI_NUM_HDA_OUT This patch adds the offset for num_playback_streams, filled on Intel platforms with the value extracted from the hardware capabilities. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ipc4: store number of playback/capture streamsPierre-Louis Bossart2-0/+13
The CHAIN_DMA IPC needs the number of playback streams as a start offset for the dma_id of a capture stream. This offset can be retrieved on Intel platforms from the GCAP information, and stored in the sof_ipc4_fw_data structure. One could argue that the fields added are not really dependent on any firmware definitions but rather on hardware capabilities, but they are required for the IPC CHAIN_DMA definitions so adding them in ipc4_fw_data isn't completely silly. The CHAIN_DMA IPC is currently only functional on Intel HDaudio DMAs, and gated by the snd_sof_is_chain_dma_supported() helper. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda-dai-ops: enable chain_dma for ALHPierre-Louis Bossart1-5/+15
Use the existing callbacks and mix/match of HDaudio and SoundWire support. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: hda: add 'is_chain_dma_supported' callbackPierre-Louis Bossart4-12/+64
Reuse existing function to get the interface mask and expose it to the SOF core with a callback - the main user is the IPC4 topology so only HDaudio platforms provide this callback. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ops: add new 'is_chain_dma_supported' callbackPierre-Louis Bossart2-0/+11
IPC4 introduced a 'chain-dma' mode when host and link DMA are connected by firmware without using a regular pipeline or the ability to add intermediate connections. This mode is not available on all platforms and all links, so add a platform-specific callback to help the SOF ipc4-topology core handle different hardware+firmware configurations. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ipc4-topology: change chain_dma handling in dai_configPierre-Louis Bossart1-5/+6
The chain_dma mode is currently only handled for HDaudio, but can be used for orther DAIs starting with LunarLake. Move the chain_dma handling earlier. Error detection for the chain_dma case for older platforms is handled at a different level. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213101247.28887-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: IPC3: fix message bounds on ipc opsCurtis Malainey1-1/+1
commit 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops") introduced a new allocation before the upper bounds check in do_rx_work. As a result A DSP can cause bad allocations if spewing garbage. Fixes: 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops") Reported-by: Tim Van Patten <timvp@google.com> Cc: stable@vger.kernel.org Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240213123834.4827-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspendPeter Ujfalusi1-1/+12
When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot. Link: https://github.com/thesofproject/sof/issues/8721 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://msgid.link/r/20240213115233.15716-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: pci-lnl: Change the topology path to intel/sof-ipc4-tplgPeter Ujfalusi1-1/+1
The firmware release which going to introduce support for Lunar Lake will use the documented default topology directory for IPC4: intel/sof-ipc4-tplg Change the default path accordingly before sof-bin (sof-firmware) release includes Lunar Lake firmware and topologies. Link: https://github.com/thesofproject/sof-docs/blob/master/getting_started/intel_debug/introduction.rst#2-topology-file Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Mengdong Lin <mengdong.lin@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://msgid.link/r/20240213080418.21256-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-13ASoC: SOF: Intel: pci-tgl: Change the default paths and firmware namesPeter Ujfalusi1-32/+32
The currently used paths and firmware name reflects the reference firmware convention: default_fw_path: intel/avs/{platform_name} default_lib_path: intel/avs-lib/{platform_name} default_tplg_path: intel/avs-tplg default_fw_filename: dsp_basefw.bin The SOF supports building the firmware for cAVS2.5 platforms using IPC4 and it is the preferred IPC4 implementation to be used on these devices. Change the paths and firmware names to reflect this: default_fw_path: intel/sof-ipc4/{platform_name} default_lib_path: intel/sof-ipc4-lib/{platform_name} default_tplg_path: intel/sof-ipc4-tplg default_fw_filename: sof-{platform_name}.ri Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240213080418.21256-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12ASoC: SOF: imx: Add devicetree support to select topologiesDaniel Baluta3-0/+36
We describe tplg_file_name and drv_name using snd_sof_of_mach array and select correct machine description based on dts compatible string. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://msgid.link/r/20240212125258.420265-1-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-11ASoC: SOF: amd: Fix locking in ACP IRQ handlerCristian Ciocaltea2-9/+10
A recent change in acp_irq_thread() was meant to address a potential race condition while trying to acquire the hardware semaphore responsible for the synchronization between firmware and host IPC interrupts. This resulted in an improper use of the IPC spinlock, causing normal kernel memory allocations (which may sleep) inside atomic contexts: 1707255557.133976 kernel: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:315 ... 1707255557.134757 kernel: sof_ipc3_rx_msg+0x70/0x130 [snd_sof] 1707255557.134793 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp] 1707255557.134855 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp] 1707255557.134904 kernel: ? irq_thread+0xb5/0x1e0 1707255557.134947 kernel: ? __pfx_irq_thread_fn+0x10/0x10 1707255557.134985 kernel: irq_thread_fn+0x23/0x60 Moreover, there are attempts to lock a mutex from the same atomic context: 1707255557.136357 kernel: ============================= 1707255557.136393 kernel: [ BUG: Invalid wait context ] 1707255557.136413 kernel: 6.8.0-rc3-next-20240206-audio-next #9 Tainted: G W 1707255557.136432 kernel: ----------------------------- 1707255557.136451 kernel: irq/66-AudioDSP/502 is trying to lock: 1707255557.136470 kernel: ffff965152f26af8 (&sb->s_type->i_mutex_key#2){+.+.}-{3:3}, at: start_creating.part.0+0x5f/0x180 ... 1707255557.137429 kernel: start_creating.part.0+0x5f/0x180 1707255557.137457 kernel: __debugfs_create_file+0x61/0x210 1707255557.137475 kernel: snd_sof_debugfs_io_item+0x75/0xc0 [snd_sof] 1707255557.137494 kernel: sof_ipc3_do_rx_work+0x7cf/0x9f0 [snd_sof] 1707255557.137513 kernel: sof_ipc3_rx_msg+0xb3/0x130 [snd_sof] 1707255557.137532 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp] 1707255557.137551 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp] Fix the issues by reducing the lock scope in acp_irq_thread(), so that it guards only the hardware semaphore acquiring attempt. Additionally, restore the initial locking in acp_sof_ipc_irq_thread() to synchronize the handling of immediate replies from DSP core. Fixes: 802134c8c2c8 ("ASoC: SOF: amd: Refactor spinlock_irq(&sdev->ipc_lock) sequence in irq_handler") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20240208234315.2182048-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-08ASoC: SOF: ipc3-topology: Fix pipeline tear down logicRanjani Sridharan1-14/+41
With the change in the widget free logic to power down the cores only when the scheduler widgets are freed, we need to ensure that the scheduler widget is freed only after all the widgets associated with the scheduler are freed. This is to ensure that the secondary core that the scheduler is scheduled to run on is kept powered on until all widgets that need them are in use. While this works well for dynamic pipelines, in the case of static pipelines the current logic does not take this into account and frees all widgets in the order they occur in the widget_list. So, modify this to ensure that the scheduler widgets are freed only after all other types of widgets in the widget_list are freed. Link: https://github.com/thesofproject/linux/issues/4807 Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores") Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20240208133432.1688-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-31soundwire/SOF: add SoundWire Interface support forMark Brown10-12/+387
Merge series from Vijendar Mukunda <Vijendar.Mukunda@amd.com>: This patch series is to redesign existing platform device creation logic for SoundWire managers and Implement generic functions for SoundWire manager probe, start and exit sequence which are common for both Legacy (NO DSP enabled) and SOF stack, and add SoundWire Interface support for AMD SOF stack (ACP 6.3 based platform). The patch series was reviewed in https://github.com/thesofproject/linux/pull/4699
2024-01-30ASoC: SOF: amd: refactor acp driver pm opsVijendar Mukunda3-5/+67
Refactor acp driver pm ops to support SoundWire interface. When SoundWire configuration is enabled, In case of ClockStopMode, DSP soft reset should be applied and for rest of the scenarios acp init/deinit sequence should be invoked. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-14-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: select soundwire dependency flag for acp6.3 based platformVijendar Mukunda1-0/+1
Select SoundWire dependency flag for acp6.3 based platform for SoundWire configuration. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-13-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: update descriptor fields for acp6.3 based platformVijendar Mukunda3-0/+12
Update acp descriptor fields for acp6.3 version based platform. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-12-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: add machine select logic for soundwire based platformsVijendar Mukunda1-4/+61
Add machine select logic for soundwire endpoints for AMD platforms. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-11-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: Add Soundwire DAI configuration support for AMD platformsVijendar Mukunda4-0/+71
Add support for configuring AMD Soundwire DAI from topology. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-10-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: add interrupt handling for SoundWire manager devicesVijendar Mukunda3-1/+46
Add support for interrupt handling for soundwire manager platform devices. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-9-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-30ASoC: SOF: amd: add code for invoking soundwire manager helper functionsVijendar Mukunda3-2/+129
Add code for invoking Soundwire manager helper functions when SoundWire configuration is selected. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240129055147.1493853-8-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-22ASoC: SOF: amd: Compute file paths on firmware loadCristian Ciocaltea2-11/+28
Commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing") changed the order of some operations and the firmware paths are not available anymore at snd_sof_probe() time. Precisely, fw_filename_prefix is set by sof_select_ipc_and_paths() via plat_data->fw_filename_prefix = out_profile.fw_path; but sof_init_environment() which calls this function was moved from snd_sof_device_probe() to sof_probe_continue(). Moreover, snd_sof_probe() was moved from sof_probe_continue() to sof_init_environment(), but before the call to sof_select_ipc_and_paths(). The problem here is that amd_sof_acp_probe() uses fw_filename_prefix to compute fw_code_bin and fw_data_bin paths, and because the field is not yet initialized, the paths end up containing (null): snd_sof_amd_vangogh 0000:04:00.5: Direct firmware load for (null)/sof-vangogh-code.bin failed with error -2 snd_sof_amd_vangogh 0000:04:00.5: sof signed firmware code bin is missing snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP firmware -2 snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2 Move usage of fw_filename_prefix right before request_firmware() calls in acp_sof_load_signed_firmware(). Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: https://msgid.link/r/20231219030728.2431640-9-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-22ASoC: SOF: core: Skip firmware test for custom loadersCristian Ciocaltea1-3/+15
The ACP driver for Vangogh platform uses a quirk for Valve Galileo device to setup a custom firmware loader, which neither requires nor uses the firmware file indicated via the default_fw_filename member of struct sof_dev_desc. Since commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing"), the provided filename gets verified and triggers a fatal error on probe: [ 7.719337] snd_sof_amd_vangogh 0000:04:00.5: enabling device (0000 -> 0002) [ 7.721486] snd_sof_amd_vangogh 0000:04:00.5: SOF firmware and/or topology file not found. [ 7.721565] snd_sof_amd_vangogh 0000:04:00.5: Supported default profiles [ 7.721569] snd_sof_amd_vangogh 0000:04:00.5: - ipc type 0 (Requested): [ 7.721573] snd_sof_amd_vangogh 0000:04:00.5: Firmware file: amd/sof/sof-vangogh.ri [ 7.721577] snd_sof_amd_vangogh 0000:04:00.5: Topology file: amd/sof-tplg/sof-vangogh-nau8821-max.tplg [ 7.721582] snd_sof_amd_vangogh 0000:04:00.5: Check if you have 'sof-firmware' package installed. [ 7.721585] snd_sof_amd_vangogh 0000:04:00.5: Optionally it can be manually downloaded from: [ 7.721589] snd_sof_amd_vangogh 0000:04:00.5: https://github.com/thesofproject/sof-bin/ [ 7.721997] snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2 According to AMD, a combined ".ri" file which includes the code and data segments cannot be used due to a limitation preventing the code image to be signed on build time. Fix the issue by skipping the firmware file test if a custom loader is being used instead of the generic one. Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing") Co-developed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://msgid.link/r/20231219030728.2431640-8-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-22ASoC: SOF: amd: Optimize quirk for Valve GalileoCristian Ciocaltea1-2/+1
Valve's Steam Deck OLED is uniquely identified by vendor and product name (Galileo) DMI fields. Simplify the quirk by removing the unnecessary match on product family. Additionally, fix the related comment as it points to the old product variant. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: https://msgid.link/r/20231219030728.2431640-7-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-22ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()Cristian Ciocaltea1-9/+19
Driver uses kasprintf() to initialize fw_{code,data}_bin members of struct acp_dev_data, but kfree() is never called to deallocate the memory, which results in a memory leak. Fix the issue by switching to devm_kasprintf(). Additionally, ensure the allocation was successful by checking the pointer validity. Fixes: f7da88003c53 ("ASoC: SOF: amd: Enable signed firmware image loading for Vangogh platform") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: https://msgid.link/r/20231219030728.2431640-6-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-16Merge tag 'asoc-fix-v6.8-merge-window' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linusTakashi Iwai3-12/+6
ASoC: Fixes for v6.8 A bunch of small fixes that come in during the merge window, mainly fixing issues from some core refactoring around dummy components that weren't detected until things reached mainline. The TAS driver changes are a little larger than normal for a device ID addition due to some shuffling around of where things are registered and DT updates but aren't really any more substantial than normal.
2024-01-15ASoC: SOF: ipc4-loader: remove the CPC check warningsKai Vehmanen1-7/+4
Warnings related to missing data in firmware manifest have proven to be too verbose. This relates to description of DSP module cost expressed in cycles per chunk (CPC). If a matching value is not found in the manifest, kernel will pass a zero value and DSP firmware will use a conservative value in its place. Downgrade the warnings to dev_dbg(). Fixes: d8a2c9879349 ("ASoC: SOF: ipc4-loader/topology: Query the CPC value from manifest") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240115092209.7184-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-15ASoC: SOF: ipc4-pcm: remove log message for LLPRander Wang1-3/+1
LLP is supported by I2S and SDW platforms but not supported by HDA platforms. This log is used to notify developer current LLP status for current device. Since above case is known to developers, the log is unnecessary and should be removed. Fixes: 7cb19007baba ("ASoC: SOF: ipc4-pcm: add hw_params") Signed-off-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240115092209.7184-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-12ASoC: SOF: icp3-dtrace: Revert "Fix wrong kfree() usage"Peter Ujfalusi1-2/+1
The offending patch introduces memory leak when there is no error, the memory allocated for the temporary storage is not freed up. As I have commented, the original code was correct and cleaner to follow but it was not obvious from the patch that it will introduce regression. Fixes: 8c91ca76f448 ("ASoC: SOF: icp3-dtrace: Fix wrong kfree() usage") Link: https://lore.kernel.org/all/aec61f67-6b4f-49e6-b458-c332983a0ad6@linux.intel.com/ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240112132749.28970-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-01-08Merge tag 'asoc-v6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linusTakashi Iwai41-436/+1095
ASoC: Updates for v6.8 This is a relatively quiet release, there's a lot of driver specific changes and the usual high level of activity in the SOF core but the one big core change was Mormioto-san's work to support more N:M CPU:CODEC mapping cases. Highlights include: - Enhanced support for N:M CPU:CODEC mappings in the core and in audio-graph-card2. - Support for falling back to older SOF IPC versions where firmware for new versions is not available. - Support for notification of control changes generated by SOF firmware with IPC4. - Device tree support for describing parts of the card which can be active over suspend (for very low power playback or wake word use cases). - ACPI parsing support for the ES83xx driver, reducing the number of quirks neede for x86 systems. - Support for more AMD and Intel systems, NXP i.MX8m MICFIL, Qualcomm SM8250, SM8550, SM8650 and X1E80100. - Removal of Freescale MPC8610 support, the SoC is no longer supported by Linux.
2024-01-08Merge branch 'for-next' into for-linusTakashi Iwai4-11/+72
Prepare for 6.8 merge. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-01-03ASoC: SOF: Intel: hda-codec: Delay the codec device registrationPeter Ujfalusi1-9/+9
The current code flow is: 1. snd_hdac_device_register() 2. set parameters needed by the hdac driver 3. request_codec_module() the hdac driver is probed at this point During boot the codec drivers are not loaded when the hdac device is registered, it is going to be probed later when loading the codec module, which point the parameters are set. On module remove/insert rmmod snd_sof_pci_intel_tgl modprobe snd_sof_pci_intel_tgl The codec module remains loaded and the driver will be probed when the hdac device is created right away, before the parameters for the driver has been configured: 1. snd_hdac_device_register() the hdac driver is probed at this point 2. set parameters needed by the hdac driver 3. request_codec_module() will be a NOP as the module is already loaded Move the snd_hdac_device_register() later, to be done right before requesting the codec module to make sure that the parameters are all set before the device is created: 1. set parameters needed by the hdac driver 2. snd_hdac_device_register() 3. request_codec_module() This way at the hdac driver probe all parameters will be set in all cases. Link: https://github.com/thesofproject/linux/issues/4731 Fixes: a0575b4add21 ("ASoC: hdac_hda: Conditionally register dais for HDMI and Analog") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20231207095425.19597-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/ZYvUIxtrqBQZbNlC@shine.dominikbrodowski.net Link: https://bugzilla.kernel.org/show_bug.cgi?id=218304 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-12-29Merge branch 'topic/cs35l41' into for-nextTakashi Iwai7-70/+118
Pull CS35L41 codec extension series. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-12-29ASoC: SOF: imx: Add SNDRV_PCM_INFO_BATCH flagShengjiu Wang3-0/+3
The sof imx pcm device is a device which should support double buffering. Found this issue with pipewire. When there is no SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will set headroom to be zero, and because sof pcm device don't support residue report, when the latency setting is small, the "delay" always larger than "target" in alsa-pcm.c, that reading next period data is not scheduled on time. With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will select a smaller period size for device, then the task of reading next period data will be scheduled on time. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1703669263-13832-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>