kernel/linux.git/sound/soc/sof/intel, branch v6.6.131

ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message

2025-09-25T09:00:09+00:00

[ Upstream commit 35fc531a59694f24a2456569cf7d1a9c6436841c ] The dev_err message is reporting an error about capture streams however it is using the incorrect variable num_playback instead of num_capture. Fix this by using the correct variable num_capture. Fixes: a1d1e266b445 ("ASoC: SOF: Intel: Add Intel specific HDA stream operations") Signed-off-by: Colin Ian King Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20250902120639.2626861-1-colin.i.king@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module

2025-03-22T19:50:43+00:00

[ Upstream commit 33b7dc7843dbdc9b90c91d11ba30b107f9138ffd ] In enviornment without KMOD requesting module may fail to load snd-hda-codec-hdmi, resulting in HDMI audio not usable. Add softdep to loading HDMI codec module first to ensure we can load it correctly. Signed-off-by: Terry Cheong Reviewed-by: Bard Liao Reviewed-by: Johny Lin Reviewed-by: Péter Ujfalusi Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: hda-dsp: Make sure that no irq handler is pending before suspend

2024-08-29T15:33:28+00:00

[ Upstream commit 576a0b71b5b479008dacb3047a346625040f5ac6 ] In the existing IPC support, the reply to each IPC message is handled in an IRQ thread. The assumption is that the IRQ thread is scheduled without significant delays. On an experimental (iow, buggy) kernel, the IRQ thread dealing with the reply to the last IPC message before powering-down the DSP can be delayed by several seconds. The IRQ thread will proceed with register accesses after the DSP is powered-down which results in a kernel crash. While the bug which causes the delay is not in the audio stack, we must handle such cases with defensive programming to avoid such crashes. Call synchronize_irq() before proceeding to power down the DSP to make sure that no irq thread is pending execution. Closes: https://github.com/thesofproject/linux/issues/4608 Reviewed-by: Guennadi Liakhovetski Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20231012191850.147140-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: hda-pcm: Limit the maximum number of periods by MAX_BDL_ENTRIES

2024-07-25T07:50:55+00:00

[ Upstream commit 82bb8db96610b558920b8c57cd250ec90567d79b ] The HDaudio specification Section 3.6.2 limits the number of BDL entries to 256. Make sure we don't allow more periods than this normative value. Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20240704090106.371497-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: hda: fix null deref on system suspend entry

2024-07-18T11:21:15+00:00

[ Upstream commit 9065693dcc13f287b9e4991f43aee70cf5538fdd ] When system enters suspend with an active stream, SOF core calls hw_params_upon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call chain of hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first, which clears hext_stream->link_substream, and then hda_ipc4_post_trigger() is called with a NULL snd_pcm_substream pointer. Fixes: 2b009fa0823c ("ASoC: SOF: Intel: hda: Unify DAI drv ops for IPC3 and IPC4") Link: https://github.com/thesofproject/linux/issues/5080 Reviewed-by: Bard Liao Signed-off-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20240704085708.371414-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: mtl: Implement firmware boot state check

2024-06-12T09:12:00+00:00

[ Upstream commit 6b1c1c47e76f0161bda2b1ac2e86a219fe70244f ] With the corrected rom_status_reg values we can now add a check for target boot status for firmware booting. With the check now we can identify failed firmware boots (IMR boots) and we can use the fallback to purge boot the DSP. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed

2024-06-12T09:12:00+00:00

[ Upstream commit 26187f44aabdf3df7609b7c78724a059c230a2ad ] In case of error during the firmware boot we need to disable the interrupts which were enabled as part of the boot sequence. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: mtl: call dsp dump when boot retry fails

2024-06-12T09:11:59+00:00

[ Upstream commit d5070d0c10326e09276c34568b9a19fb9a727b6e ] Call snd_sof_dsp_dbg_dump() with the same flags/dump_msg as used in function hda_loader.c/cl_dsp_init(). Reviewed-by: Péter Ujfalusi Signed-off-by: Yong Zhi Signed-off-by: Pierre-Louis Bossart Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20231127105235.30071-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: 26187f44aabd ("ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed") Signed-off-by: Sasha Levin

ASoC: SOF: Intel: lnl: Correct rom_status_reg

2024-06-12T09:11:59+00:00

[ Upstream commit b852574c671a9983dd51c81582c8c5085f3dc382 ] ACE2 architecture changed the place where the ROM updates the status code from the shared SRAM window (and HFFLGP1QW0 in ACE1) to HFDSC register for the status and HFDEC (HFDSC + 4) for the error code. The rom_status_reg is not used on LNL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Add new header file for lnl specific register definitions. Fixes: 64a63d9914a5 ("ASoC: SOF: Intel: LNL: Add support for Lunarlake platform") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: Intel: mtl: Correct rom_status_reg

2024-06-12T09:11:59+00:00

[ Upstream commit 1f1b820dc3c65b6883da3130ba3b8624dcbf87db ] ACE1 architecture changed the place where the ROM updates the status code from the shared SRAM window to HFFLGP1QW0 register for the status and HFFLGP1QW0 + 4 for the error code. The rom_status_reg is not used on MTL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin