summaryrefslogtreecommitdiff
path: root/sound/soc/sof
AgeCommit message (Collapse)Author
2024-03-26ASoC: SOF: ipc4/Intel: Fix delay reportingMark Brown
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: The current version of delay reporting code can report incorrect values when paired with a firmware which enables this feature. Unfortunately there are several smaller issues that needed to be addressed to correct the behavior: Wrong information was used for the host side of counter For MTL/LNL used incorrect (in a sense that it was verified only on MTL) link side counter function. The link side counter needs compensation logic if pause/resume is used. The offset values were not refreshed from firmware. Finally, not strictly connected, but the ALSA buffer size needs to be constrained to avoid constant xrun from media players (like mpv) The series applies cleanly for 6.9 and 6.8.y stable, but older stable would need manual backport, but it is questionable if it is needed as MTL/LNL is missing features.
2024-03-25ASoC: SOF: mtrace: rework mtrace timestamp settingRander Wang
The original timestamp is built base on windows epoch time which is not fit for Linux system and difficult to be used for kernel debugging. This patch adopts syslog timestamp so that we can simply use dmesg to check the timestamp between fw and kernel. 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://msgid.link/r/20240322112703.4549-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: hda-dsp: Skip IMR boot on ACE platforms in case of S3 suspendPeter Ujfalusi
SoCs with ACE architecture are tailored to use s2idle instead deep (S3) suspend state and the IMR content is lost when the system is forced to enter even to S3. When waking up from S3 state the IMR boot will fail as the content is lost. Set the skip_imr_boot flag to make sure that we don't try IMR in this case. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://msgid.link/r/20240322112504.4192-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: hda: Compensate LLP in case it is not resetPeter Ujfalusi
During pause/reset or stop/start the LLP counter is not reset, which will result broken delay reporting. Read the LLP value on STOP/PAUSE trigger and use it in LLP reading to normalize the LLP from the register. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-18-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-pcm: Correct the delay calculationPeter Ujfalusi
This patch improves the delay calculation by relying on the LLP (Linear Link Position) on the DAI side and the LDP (Linear Data Pointer) on the host side. The LDP provides the same DMA position as LPIB, but with a linear count instead of a position in the ALSA ring buffer. The LDP values are provided in bytes and must be converted to frames. The difference in units means that the host counter will wrap earlier than the LLP. We need to wrap the LLP at the same boundary as the host counter. The ASoC framework relies on separate pointer and delay callback. Measurement errors can be reduced by processing all the counter values in the pointer callback. The delay value is stored, and will be reported to higher levels in the delay callback. For playback, the firmware provides a stream_start offset to handle mixing/pause usages, where the DAI might have started earlier than the PCM device. The delay calculation must be special-cased when the link counter has not reached the start offset value, i.e. no valid audio has left the DSP. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-16-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: sof-pcm: Add pointer callback to sof_ipc_pcm_opsPeter Ujfalusi
The IPC specific pointer callback can be used when additional or custom handling is needed during the pointer calculation, like executing a delay calculation at the same time to minimize drift between the reported pointer and the calculated delay. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-15-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-pcm: Invalidate the stream_start_offset in PAUSED statePeter Ujfalusi
When the final state is SOF_IPC4_PIPE_PAUSED, it is possible that the stream will be restarted (resume or start) in which case we need to update the offset from the firmware. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-14-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-pcm: Combine the SOF_IPC4_PIPE_PAUSED cases in pcm_triggerPeter Ujfalusi
The SNDRV_PCM_TRIGGER_PAUSE_PUSH does not need to be a separate case, it can be handled along with STOP and SUSPEND Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-13-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-pcm: Move struct sof_ipc4_timestamp_info definition locallyPeter Ujfalusi
The sof_ipc4_timestamp_info is only used by ipc4-pcm.c internally, it should not be in a generic header implying that it might be used elsewhere. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Remove the get_stream_position callbackPeter Ujfalusi
The get_stream_position has been replaced by get_dai_frame_counter and all related code can be dropped form the core. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-11-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: hda-common-ops: Do not set the get_stream_position callbackPeter Ujfalusi
The get_stream_position has been replaced by get_dai_frame_counter, it should not be set to allow it to be dropped from core code. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-pcm: Use the snd_sof_pcm_get_dai_frame_counter() for pcm_delayPeter Ujfalusi
Switch to the new callback to retrieve the DAI (link) frame counter. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: Set the dai/host get frame/byte counter callbacksPeter Ujfalusi
Add implementation for reading the LDP (Linear DMA Position) to be used as get_host_byte_counter(). The LDP is counting the number of bytes moved between the DSP and host memory. Set the get_dai_frame_counter to hda_dsp_get_stream_llp, which is counting the frames on the link side of the DSP. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Introduce a new callback pair to be used for PCM delay reportingPeter Ujfalusi
For delay calculation we need two information: Number of bytes transferred between the DSP and host memory (ALSA buffer) Number of frames transferred between the DSP and external device (link/codec/DMIC/etc). The reason for the different units (bytes vs frames) on host and dai side is that the format on the dai side is decided by the firmware and might not be the same as on the host side, thus the expectation is that the counter reflects the number of frames. The kernel know the host side format and in there we have access to the DMA position which is in bytes. In a simplified way, the DSP caused delay is the difference between the two counters. The existing get_stream_position callback is defined to retrieve the frame counter on the DAI side but it's name is too generic to be intuitive and makes it hard to define a callback for the host side. This patch introduces a new set of callbacks to replace the get_stream_position and define the host side equivalent: get_dai_frame_counter get_host_byte_counter Subsequent patches will remove the old callback. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: mtl/lnl: Use the generic get_stream_position callbackPeter Ujfalusi
Drop the MTL mtl_dsp_get_stream_hda_link_position() function and related defines since it can only work on platforms which have 19 streams because of the use of 0x948 as base offset for the LLP registers. The generic hda_dsp_get_stream_hda_link_position() takes the number of streams into consideration when reading the LLP registers for the stream and can handle different HDA configurations. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240321130814.4412-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: hda: Implement get_stream_position (Linear Link Position)Peter Ujfalusi
When the Linear Link Position is not available in firmware SRAM window we use the host accessible position registers to read it. The address of the PPLCLLPL/U registers depend on the number of streams (playback+capture). At probe time the pplc_addr is calculated for each stream and we can use it to read the LLP without the need of address re-calculation. Set the get_stream_position callback in sof_hda_common_ops for all platforms: The callback is used for IPC4 delay calculations only but the register is a generic HDA register, not tied to any specific IPC version. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240321130814.4412-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraintPeter Ujfalusi
If the PCM have the dsp_max_burst_size_in_ms set then place a constraint to limit the minimum buffer time to avoid xruns caused by DMA bursts spinning on the ALSA buffer. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: ipc4-topology: Save the DMA maximum burst size for PCMsPeter Ujfalusi
When setting up the pcm widget, save the DSP buffer size (in ms) for platform code to place a constraint on playback. On playback the DMA will fill the buffer on start and if the period size is smaller it will immediately overrun. On capture the DMA will move data in 1ms bursts. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-25ASoC: SOF: Add dsp_max_burst_size_in_ms member to snd_sof_pcm_streamPeter Ujfalusi
The dsp_max_burst_size_in_ms can be used to save the length of the maximum burst size in ms the host DMA will use. Platform code can place constraint using this to avoid user space requesting too small ALSA buffer which will result xruns. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20240321130814.4412-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-15ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLEDCristian Ciocaltea
The recent introduction of the ACP/PSP communication for IRAM/DRAM fence register modification breaks the audio support on Valve's Steam Deck OLED device. It causes IPC timeout errors when trying to load DSP topology during probing: 1707255557.688176 kernel: snd_sof_amd_vangogh 0000:04:00.5: ipc tx timed out for 0x30100000 (msg/reply size: 48/0) 1707255557.689035 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump start ]------------ 1707255557.689421 kernel: snd_sof_amd_vangogh 0000:04:00.5: dsp_msg = 0x0 dsp_ack = 0x91d14f6f host_msg = 0x1 host_ack = 0xead0f1a4 irq_stat > 1707255557.689730 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump end ]------------ 1707255557.690074 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump start ]------------ 1707255557.690376 kernel: snd_sof_amd_vangogh 0000:04:00.5: IPC timeout 1707255557.690744 kernel: snd_sof_amd_vangogh 0000:04:00.5: fw_state: SOF_FW_BOOT_COMPLETE (7) 1707255557.691037 kernel: snd_sof_amd_vangogh 0000:04:00.5: invalid header size 0xdb43fe7. FW oops is bogus 1707255557.694824 kernel: snd_sof_amd_vangogh 0000:04:00.5: unexpected fault 0x6942d3b3 trace 0x6942d3b3 1707255557.695392 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump end ]------------ 1707255557.695755 kernel: snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN 1707255557.696069 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -110 1707255557.696374 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22 1707255557.697904 kernel: snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22 1707255557.698405 kernel: sof_mach nau8821-max: ASoC: failed to instantiate card -22 1707255557.701061 kernel: sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max) 1707255557.701624 kernel: sof_mach: probe of nau8821-max failed with error -22 Introduce a new member skip_iram_dram_size_mod to struct acp_quirk_entry and use it to skip IRAM/DRAM size modification for Vangogh Galileo device. Fixes: 55d7bbe43346 ("ASoC: SOF: amd: Add acp-psp mailbox interface for iram-dram fence register modification") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://msgid.link/r/20240220201623.438944-3-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-15ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entryCristian Ciocaltea
The signed_fw_image member of struct sof_amd_acp_desc is used to enable signed firmware support in the driver via the acp_sof_quirk_table. In preparation to support additional use cases of the quirk table (i.e. adding new flags), move signed_fw_image to a new struct acp_quirk_entry and update all references to it accordingly. No functional changes intended. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://msgid.link/r/20240220201623.438944-2-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-21ASoC: Intel: avs: Fixes and new platforms supportMark Brown
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 Bergmann
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 Carpenter
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 Brown
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 Brown
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 Liao
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 Ujfalusi
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 Bossart
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 Ujfalusi
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 Bossart
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 Bossart
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 Sridharan
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Bossart
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 Malainey
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 Ujfalusi
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 Ujfalusi
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 Ujfalusi
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 Baluta
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 Ciocaltea
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 Sridharan
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>