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

Re: [PATCH] ASoC: SOF: amd: Move depends on AMD_NODE to consumers
by Mark Brown 25 Feb '25

25 Feb '25

On Fri, 21 Feb 2025 12:18:12 -0600, Mario Limonciello wrote: > CONFIG_SND_SOC_SOF_AMD_COMMON is a hidden option that is only selected by > other options. It can't have a direct depends on AMD_NODE because select > can't pick another option automatically. > > This was attempted to be fixed in commit b47834ee4485b ("ASoC: SOF: amd: > Add depends on CPU_SUP_AMD") but this just masked the issue as it was found > in another config. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Move depends on AMD_NODE to consumers commit: 91b75129149429bb16927cda8b5642c04c59e6b0 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

[PATCH AUTOSEL 5.10 4/7] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 8d65004c917a1..aed8440ef525a 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -260,6 +260,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

[PATCH AUTOSEL 5.15 3/7] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 6744318de612e..0449e7a2669ff 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -258,6 +258,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

[PATCH AUTOSEL 6.1 06/12] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index a0dfd7de431fe..a75f81116643b 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -282,6 +282,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

[PATCH AUTOSEL 6.6 10/20] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
by Sasha Levin 24 Feb '25

24 Feb '25

From: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> [ Upstream commit ac84ca815adb4171a4276b1d44096b75f6a150b7 ] In some cases, e.g. during resuming from suspend, there is a possibility that some IPC reply messages get received by the host while the DSP firmware has not yet reached the complete boot state. Detect when this happens and do not attempt to process the unexpected replies from DSP. Instead, provide proper debugging support. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Link: https://patch.msgid.link/20250207-sof-vangogh-fixes-v1-3-67824c1e4c9a@colla… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index fcb54f545fea3..a4e9bc20adaff 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) { acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status)); + if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) { snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status), true); @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write); if (dsp_ack) { - spin_lock_irq(&sdev->ipc_lock); - /* handle immediate reply from DSP core */ - acp_dsp_ipc_get_reply(sdev); - snd_sof_ipc_reply(sdev, 0); - /* set the done bit */ - acp_dsp_ipc_dsp_done(sdev); - spin_unlock_irq(&sdev->ipc_lock); + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) { + spin_lock_irq(&sdev->ipc_lock); + + /* handle immediate reply from DSP core */ + acp_dsp_ipc_get_reply(sdev); + snd_sof_ipc_reply(sdev, 0); + /* set the done bit */ + acp_dsp_ipc_dsp_done(sdev); + + spin_unlock_irq(&sdev->ipc_lock); + } else { + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n", + dsp_ack); + } + ipc_irq = true; } -- 2.39.5

1 0

[PATCH AUTOSEL 6.6 09/20] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 328d7c227b218..82a6707fb4b80 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -444,6 +444,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS_GPL(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

[PATCH AUTOSEL 6.12 18/28] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
by Sasha Levin 24 Feb '25

24 Feb '25

From: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> [ Upstream commit ac84ca815adb4171a4276b1d44096b75f6a150b7 ] In some cases, e.g. during resuming from suspend, there is a possibility that some IPC reply messages get received by the host while the DSP firmware has not yet reached the complete boot state. Detect when this happens and do not attempt to process the unexpected replies from DSP. Instead, provide proper debugging support. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Link: https://patch.msgid.link/20250207-sof-vangogh-fixes-v1-3-67824c1e4c9a@colla… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index b44b1b1adb6ed..cf3994a705f94 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) { acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status)); + if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) { snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status), true); @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write); if (dsp_ack) { - spin_lock_irq(&sdev->ipc_lock); - /* handle immediate reply from DSP core */ - acp_dsp_ipc_get_reply(sdev); - snd_sof_ipc_reply(sdev, 0); - /* set the done bit */ - acp_dsp_ipc_dsp_done(sdev); - spin_unlock_irq(&sdev->ipc_lock); + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) { + spin_lock_irq(&sdev->ipc_lock); + + /* handle immediate reply from DSP core */ + acp_dsp_ipc_get_reply(sdev); + snd_sof_ipc_reply(sdev, 0); + /* set the done bit */ + acp_dsp_ipc_dsp_done(sdev); + + spin_unlock_irq(&sdev->ipc_lock); + } else { + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n", + dsp_ack); + } + ipc_irq = true; } -- 2.39.5

1 0

[PATCH AUTOSEL 6.12 17/28] ASoC: SOF: amd: Add post_fw_run_delay ACP quirk
by Sasha Levin 24 Feb '25

24 Feb '25

From: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> [ Upstream commit 91b98d5a6e8067c5226207487681a48f0d651e46 ] Stress testing resume from suspend on Valve Steam Deck OLED (Galileo) revealed that the DSP firmware could enter an unrecoverable faulty state, where the kernel ring buffer is flooded with IPC related error messages: [ +0.017002] snd_sof_amd_vangogh 0000:04:00.5: acp_sof_ipc_send_msg: Failed to acquire HW lock [ +0.000054] snd_sof_amd_vangogh 0000:04:00.5: ipc3_tx_msg_unlocked: ipc message send for 0x30100000 failed: -22 [ +0.000005] snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN [ +0.000004] snd_sof_amd_vangogh 0000:04:00.5: Failed to restore pipeline after resume -22 [ +0.000003] snd_sof_amd_vangogh 0000:04:00.5: PM: dpm_run_callback(): pci_pm_resume returns -22 [ +0.000009] snd_sof_amd_vangogh 0000:04:00.5: PM: failed to resume async: error -22 [...] [ +0.002582] PM: suspend exit [ +0.065085] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for 0x30130000 (msg/reply size: 12/0): -22 [ +0.000499] snd_sof_amd_vangogh 0000:04:00.5: error: failed widget list set up for pcm 1 dir 0 [ +0.000011] snd_sof_amd_vangogh 0000:04:00.5: error: set pcm hw_params after resume [ +0.000006] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_pcm_component_prepare on 0000:04:00.5: -22 [...] A system reboot would be necessary to restore the speakers functionality. However, by delaying a bit any host to DSP transmission right after the firmware boot completed, the issue could not be reproduced anymore and sound continued to work flawlessly even after performing thousands of suspend/resume cycles. Introduce the post_fw_run_delay ACP quirk to allow providing the aforementioned delay via the snd_sof_dsp_ops->post_fw_run() callback for the affected devices. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Link: https://patch.msgid.link/20250207-sof-vangogh-fixes-v1-1-67824c1e4c9a@colla… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp.c | 1 + sound/soc/sof/amd/acp.h | 1 + sound/soc/sof/amd/vangogh.c | 18 ++++++++++++++++++ 3 files changed, 20 insertions(+) diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 95d4762c9d939..35eb23d2a056d 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -27,6 +27,7 @@ MODULE_PARM_DESC(enable_fw_debug, "Enable Firmware debug"); static struct acp_quirk_entry quirk_valve_galileo = { .signed_fw_image = true, .skip_iram_dram_size_mod = true, + .post_fw_run_delay = true, }; const struct dmi_system_id acp_sof_quirk_table[] = { diff --git a/sound/soc/sof/amd/acp.h b/sound/soc/sof/amd/acp.h index 800594440f739..2a19d82d62002 100644 --- a/sound/soc/sof/amd/acp.h +++ b/sound/soc/sof/amd/acp.h @@ -220,6 +220,7 @@ struct sof_amd_acp_desc { struct acp_quirk_entry { bool signed_fw_image; bool skip_iram_dram_size_mod; + bool post_fw_run_delay; }; /* Common device data struct for ACP devices */ diff --git a/sound/soc/sof/amd/vangogh.c b/sound/soc/sof/amd/vangogh.c index 61372958c09dc..436f58be3a9f9 100644 --- a/sound/soc/sof/amd/vangogh.c +++ b/sound/soc/sof/amd/vangogh.c @@ -11,6 +11,7 @@ * Hardware interface for Audio DSP on Vangogh platform */ +#include <linux/delay.h> #include <linux/platform_device.h> #include <linux/module.h> @@ -136,6 +137,20 @@ static struct snd_soc_dai_driver vangogh_sof_dai[] = { }, }; +static int sof_vangogh_post_fw_run_delay(struct snd_sof_dev *sdev) +{ + /* + * Resuming from suspend in some cases my cause the DSP firmware + * to enter an unrecoverable faulty state. Delaying a bit any host + * to DSP transmission right after firmware boot completion seems + * to resolve the issue. + */ + if (!sdev->first_boot) + usleep_range(100, 150); + + return 0; +} + /* Vangogh ops */ struct snd_sof_dsp_ops sof_vangogh_ops; EXPORT_SYMBOL_NS(sof_vangogh_ops, SND_SOC_SOF_AMD_COMMON); @@ -157,6 +172,9 @@ int sof_vangogh_ops_init(struct snd_sof_dev *sdev) if (quirks->signed_fw_image) sof_vangogh_ops.load_firmware = acp_sof_load_signed_firmware; + + if (quirks->post_fw_run_delay) + sof_vangogh_ops.post_fw_run = sof_vangogh_post_fw_run_delay; } return 0; -- 2.39.5

1 0

[PATCH AUTOSEL 6.12 15/28] ASoC: SOF: Intel: pci-ptl: Add support for PTL-H
by Sasha Levin 24 Feb '25

24 Feb '25

From: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> [ Upstream commit 4e9c87cfcd0584f2a2e2f352a43ff003d688f3a4 ] PTL-H uses the same configuration as PTL. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Acked-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://patch.msgid.link/20250210081730.22916-4-peter.ujfalusi@linux.intel.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/pci-ptl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/pci-ptl.c b/sound/soc/sof/intel/pci-ptl.c index 69195b5e7b1a9..f54d098d616f6 100644 --- a/sound/soc/sof/intel/pci-ptl.c +++ b/sound/soc/sof/intel/pci-ptl.c @@ -50,6 +50,7 @@ static const struct sof_dev_desc ptl_desc = { /* PCI IDs */ static const struct pci_device_id sof_pci_ids[] = { { PCI_DEVICE_DATA(INTEL, HDA_PTL, &ptl_desc) }, /* PTL */ + { PCI_DEVICE_DATA(INTEL, HDA_PTL_H, &ptl_desc) }, /* PTL-H */ { 0, } }; MODULE_DEVICE_TABLE(pci, sof_pci_ids); -- 2.39.5

1 0

[PATCH AUTOSEL 6.12 12/28] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index dc46888faa0dc..c0c58b4297155 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -454,6 +454,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS_GPL(hda_codec_i915_exit, SND_SOC_SOF_HDA_AUDIO_CODEC_I915); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

[PATCH AUTOSEL 6.13 20/32] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
by Sasha Levin 24 Feb '25

24 Feb '25

From: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> [ Upstream commit ac84ca815adb4171a4276b1d44096b75f6a150b7 ] In some cases, e.g. during resuming from suspend, there is a possibility that some IPC reply messages get received by the host while the DSP firmware has not yet reached the complete boot state. Detect when this happens and do not attempt to process the unexpected replies from DSP. Instead, provide proper debugging support. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Link: https://patch.msgid.link/20250207-sof-vangogh-fixes-v1-3-67824c1e4c9a@colla… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index 5f371d9263f3b..12caefd087885 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) { acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status)); + if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) { snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status), true); @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write); if (dsp_ack) { - spin_lock_irq(&sdev->ipc_lock); - /* handle immediate reply from DSP core */ - acp_dsp_ipc_get_reply(sdev); - snd_sof_ipc_reply(sdev, 0); - /* set the done bit */ - acp_dsp_ipc_dsp_done(sdev); - spin_unlock_irq(&sdev->ipc_lock); + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) { + spin_lock_irq(&sdev->ipc_lock); + + /* handle immediate reply from DSP core */ + acp_dsp_ipc_get_reply(sdev); + snd_sof_ipc_reply(sdev, 0); + /* set the done bit */ + acp_dsp_ipc_dsp_done(sdev); + + spin_unlock_irq(&sdev->ipc_lock); + } else { + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n", + dsp_ack); + } + ipc_irq = true; } -- 2.39.5

1 0

[PATCH AUTOSEL 6.13 19/32] ASoC: SOF: amd: Add post_fw_run_delay ACP quirk
by Sasha Levin 24 Feb '25

24 Feb '25

From: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> [ Upstream commit 91b98d5a6e8067c5226207487681a48f0d651e46 ] Stress testing resume from suspend on Valve Steam Deck OLED (Galileo) revealed that the DSP firmware could enter an unrecoverable faulty state, where the kernel ring buffer is flooded with IPC related error messages: [ +0.017002] snd_sof_amd_vangogh 0000:04:00.5: acp_sof_ipc_send_msg: Failed to acquire HW lock [ +0.000054] snd_sof_amd_vangogh 0000:04:00.5: ipc3_tx_msg_unlocked: ipc message send for 0x30100000 failed: -22 [ +0.000005] snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN [ +0.000004] snd_sof_amd_vangogh 0000:04:00.5: Failed to restore pipeline after resume -22 [ +0.000003] snd_sof_amd_vangogh 0000:04:00.5: PM: dpm_run_callback(): pci_pm_resume returns -22 [ +0.000009] snd_sof_amd_vangogh 0000:04:00.5: PM: failed to resume async: error -22 [...] [ +0.002582] PM: suspend exit [ +0.065085] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for 0x30130000 (msg/reply size: 12/0): -22 [ +0.000499] snd_sof_amd_vangogh 0000:04:00.5: error: failed widget list set up for pcm 1 dir 0 [ +0.000011] snd_sof_amd_vangogh 0000:04:00.5: error: set pcm hw_params after resume [ +0.000006] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_pcm_component_prepare on 0000:04:00.5: -22 [...] A system reboot would be necessary to restore the speakers functionality. However, by delaying a bit any host to DSP transmission right after the firmware boot completed, the issue could not be reproduced anymore and sound continued to work flawlessly even after performing thousands of suspend/resume cycles. Introduce the post_fw_run_delay ACP quirk to allow providing the aforementioned delay via the snd_sof_dsp_ops->post_fw_run() callback for the affected devices. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Link: https://patch.msgid.link/20250207-sof-vangogh-fixes-v1-1-67824c1e4c9a@colla… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp.c | 1 + sound/soc/sof/amd/acp.h | 1 + sound/soc/sof/amd/vangogh.c | 18 ++++++++++++++++++ 3 files changed, 20 insertions(+) diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 33648ff8b8336..9e13c96528be3 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -27,6 +27,7 @@ MODULE_PARM_DESC(enable_fw_debug, "Enable Firmware debug"); static struct acp_quirk_entry quirk_valve_galileo = { .signed_fw_image = true, .skip_iram_dram_size_mod = true, + .post_fw_run_delay = true, }; const struct dmi_system_id acp_sof_quirk_table[] = { diff --git a/sound/soc/sof/amd/acp.h b/sound/soc/sof/amd/acp.h index 800594440f739..2a19d82d62002 100644 --- a/sound/soc/sof/amd/acp.h +++ b/sound/soc/sof/amd/acp.h @@ -220,6 +220,7 @@ struct sof_amd_acp_desc { struct acp_quirk_entry { bool signed_fw_image; bool skip_iram_dram_size_mod; + bool post_fw_run_delay; }; /* Common device data struct for ACP devices */ diff --git a/sound/soc/sof/amd/vangogh.c b/sound/soc/sof/amd/vangogh.c index 8e2672106ac60..d5f1dddd43e72 100644 --- a/sound/soc/sof/amd/vangogh.c +++ b/sound/soc/sof/amd/vangogh.c @@ -11,6 +11,7 @@ * Hardware interface for Audio DSP on Vangogh platform */ +#include <linux/delay.h> #include <linux/platform_device.h> #include <linux/module.h> @@ -136,6 +137,20 @@ static struct snd_soc_dai_driver vangogh_sof_dai[] = { }, }; +static int sof_vangogh_post_fw_run_delay(struct snd_sof_dev *sdev) +{ + /* + * Resuming from suspend in some cases my cause the DSP firmware + * to enter an unrecoverable faulty state. Delaying a bit any host + * to DSP transmission right after firmware boot completion seems + * to resolve the issue. + */ + if (!sdev->first_boot) + usleep_range(100, 150); + + return 0; +} + /* Vangogh ops */ struct snd_sof_dsp_ops sof_vangogh_ops; EXPORT_SYMBOL_NS(sof_vangogh_ops, "SND_SOC_SOF_AMD_COMMON"); @@ -157,6 +172,9 @@ int sof_vangogh_ops_init(struct snd_sof_dev *sdev) if (quirks->signed_fw_image) sof_vangogh_ops.load_firmware = acp_sof_load_signed_firmware; + + if (quirks->post_fw_run_delay) + sof_vangogh_ops.post_fw_run = sof_vangogh_post_fw_run_delay; } return 0; -- 2.39.5

1 0

[PATCH AUTOSEL 6.13 17/32] ASoC: SOF: Intel: pci-ptl: Add support for PTL-H
by Sasha Levin 24 Feb '25

24 Feb '25

From: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> [ Upstream commit 4e9c87cfcd0584f2a2e2f352a43ff003d688f3a4 ] PTL-H uses the same configuration as PTL. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Acked-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://patch.msgid.link/20250210081730.22916-4-peter.ujfalusi@linux.intel.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/pci-ptl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/pci-ptl.c b/sound/soc/sof/intel/pci-ptl.c index 0aacdfac9fb43..c4fb6a2441b76 100644 --- a/sound/soc/sof/intel/pci-ptl.c +++ b/sound/soc/sof/intel/pci-ptl.c @@ -50,6 +50,7 @@ static const struct sof_dev_desc ptl_desc = { /* PCI IDs */ static const struct pci_device_id sof_pci_ids[] = { { PCI_DEVICE_DATA(INTEL, HDA_PTL, &ptl_desc) }, /* PTL */ + { PCI_DEVICE_DATA(INTEL, HDA_PTL_H, &ptl_desc) }, /* PTL-H */ { 0, } }; MODULE_DEVICE_TABLE(pci, sof_pci_ids); -- 2.39.5

1 0

[PATCH AUTOSEL 6.13 14/32] ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi module
by Sasha Levin 24 Feb '25

24 Feb '25

From: Terry Cheong <htcheong(a)chromium.org> [ 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 <htcheong(a)chromium.org> Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Johny Lin <lpg76627(a)gmail.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://patch.msgid.link/20250206094723.18013-1-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 568f3dfe822f5..2f9925830d1d5 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -454,6 +454,7 @@ int hda_codec_i915_exit(struct snd_sof_dev *sdev) } EXPORT_SYMBOL_NS_GPL(hda_codec_i915_exit, "SND_SOC_SOF_HDA_AUDIO_CODEC_I915"); +MODULE_SOFTDEP("pre: snd-hda-codec-hdmi"); #endif MODULE_LICENSE("Dual BSD/GPL"); -- 2.39.5

1 0

Re: [PATCH] ASoC: SOF: amd: Add depends on CPU_SUP_AMD
by Mark Brown 20 Feb '25

20 Feb '25

On Thu, 20 Feb 2025 12:48:20 -0600, Mario Limonciello wrote: > When SMN support was switched to the kernel wide AMD_NODE instead of > local implementation this broke compilation on the allyesconfig for > some architectures. AMD_NODE is only supported on AMD platforms, so > modify all the AMD drivers that use it to also require CPU_SUP_AMD. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Add depends on CPU_SUP_AMD commit: b47834ee4485bbdcc6d36f086ff61c3efd8870d4 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: (subset) [PATCH 0/7] Adjust all AMD audio drivers to use AMD_NODE
by Mark Brown 20 Feb '25

20 Feb '25

On Mon, 17 Feb 2025 17:17:40 -0600, Mario Limonciello wrote: > The various AMD audio drivers have self contained implementations > for SMN router communication that require hardcoding the bridge ID. > > These implementations also don't prevent race conditions with other > drivers performing SMN communication. > > A new centralized driver AMD_NODE is introduced and all drivers in > the kernel should use this instead. Adjust all AMD audio drivers to > use it. > Mario Limonciello (7): > x86/amd_node: Add a helper for use with `read_poll_timeout` > ASoC: amd: acp: rembrandt: Use AMD_NODE > ASoC: amd: acp: acp70: Use AMD_NODE > ASoC: amd: acp: acp63: Use AMD_NODE > ASoC: SOF: amd: Use AMD_NODE > ASoC: amd: acp: Drop local symbols for smn read/write > ASoC: SOF: amd: Drop host bridge ID from struct > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [2/7] ASoC: amd: acp: rembrandt: Use AMD_NODE commit: e211adcf36d0ccdd31af7398af4725a47d74b3d4 [3/7] ASoC: amd: acp: acp70: Use AMD_NODE commit: 135c6af1cac5465529469700d16c0c44b24ce317 [4/7] ASoC: amd: acp: acp63: Use AMD_NODE commit: 8f969537149d672d40a0e75a83f39451a5402780 [5/7] ASoC: SOF: amd: Use AMD_NODE commit: f120cf33d2325fd95d063eccbff2e86ffc7f493a [6/7] ASoC: amd: acp: Drop local symbols for smn read/write commit: 40d05927830227f2a1701c61e8bbe65287a03490 [7/7] ASoC: SOF: amd: Drop host bridge ID from struct commit: a261d77fec147b9974aacca8ae8f0693feede838 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH 1/2] ASoC: SOF: imx: Fix an IS_ERR() vs NULL bug in imx_parse_ioremap_memory()
by Mark Brown 18 Feb '25

18 Feb '25

On Mon, 17 Feb 2025 10:32:44 +0300, Dan Carpenter wrote: > The devm_ioremap() function doesn't return error pointers, it returns > NULL on error. Update the checking to match. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: SOF: imx: Fix an IS_ERR() vs NULL bug in imx_parse_ioremap_memory() commit: b20be2c77ce5341ded1a2d8aec119f6dca8ef1ad [2/2] ASoC: SOF: imx: Fix error code in probe() commit: a78f244a9150da0878a37a1b59fb0608b1ccfb9d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: Intel: Use str_enable_disable() helper
by Mark Brown 17 Feb '25

17 Feb '25

On Mon, 10 Feb 2025 13:01:30 +0100, Thorsten Blum wrote: > Remove hard-coded strings by using the str_enable_disable() helper > function. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: Intel: Use str_enable_disable() helper commit: e08fe24c34d37d00e84009f2fb4c35f5978041e6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: ipc3: Use str_enabled_disabled() helper function
by Mark Brown 17 Feb '25

17 Feb '25

On Mon, 10 Feb 2025 23:44:54 +0100, Thorsten Blum wrote: > Remove hard-coded strings by using the str_enabled_disabled() helper > function. Remove unnecessary curly braces. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc3: Use str_enabled_disabled() helper function commit: e0f421d73053eaeb441aa77054b75992705656c7 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: Intel: Don't import non-existing module namespace
by Mark Brown 17 Feb '25

17 Feb '25

On Wed, 12 Feb 2025 18:29:47 +0100, Uwe Kleine-König wrote: > There is no module namespace "SND_SOC_SOF_INTEL_HIFI_EP_IPC", so don't > import it. Historically there was such a namespace, but it was dropped > in commit 97e22cbd0dc3 ("ASoC: SOF: Make Intel IPC stream ops generic"). > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: Intel: Don't import non-existing module namespace commit: 9dc016eaba3a70febcd1db5f1a0beeb7430166aa All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH 0/4] Sound fix for Valve Steam Deck OLED on resume from suspend
by Mark Brown 10 Feb '25

10 Feb '25

On Fri, 07 Feb 2025 13:46:01 +0200, Cristian Ciocaltea wrote: > Stress testing resume from suspend on Valve Steam Deck OLED (Galileo) > revealed that audio may break and cannot be recovered without performing > a system reboot. > > This patch series provides a new ACP quirk to address the issue, along > with a few additional improvements to AMD Vangogh/ACP SOF drivers. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: SOF: amd: Add post_fw_run_delay ACP quirk commit: 91b98d5a6e8067c5226207487681a48f0d651e46 [2/4] ASoC: SOF: amd: Drop unused includes from Vangogh driver commit: 2ecbc2e9f3b19e2199e8bc3ba603d299f1985f09 [3/4] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE commit: ac84ca815adb4171a4276b1d44096b75f6a150b7 [4/4] ASoC: SOF: amd: Add branch prediction hint in ACP IRQ handler commit: ccc8480d90e8cb60f06bd90e227f34784927e19f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH 1/4] ASoC: SOF: amd: Add post_fw_run_delay ACP quirk
by Mukunda,Vijendar 07 Feb '25

07 Feb '25

On 07/02/25 17:16, Cristian Ciocaltea wrote: > Stress testing resume from suspend on Valve Steam Deck OLED (Galileo) > revealed that the DSP firmware could enter an unrecoverable faulty > state, where the kernel ring buffer is flooded with IPC related error > messages: > > [ +0.017002] snd_sof_amd_vangogh 0000:04:00.5: acp_sof_ipc_send_msg: Failed to acquire HW lock > [ +0.000054] snd_sof_amd_vangogh 0000:04:00.5: ipc3_tx_msg_unlocked: ipc message send for 0x30100000 failed: -22 > [ +0.000005] snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN > [ +0.000004] snd_sof_amd_vangogh 0000:04:00.5: Failed to restore pipeline after resume -22 > [ +0.000003] snd_sof_amd_vangogh 0000:04:00.5: PM: dpm_run_callback(): pci_pm_resume returns -22 > [ +0.000009] snd_sof_amd_vangogh 0000:04:00.5: PM: failed to resume async: error -22 > [...] > [ +0.002582] PM: suspend exit > [ +0.065085] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for 0x30130000 (msg/reply size: 12/0): -22 > [ +0.000499] snd_sof_amd_vangogh 0000:04:00.5: error: failed widget list set up for pcm 1 dir 0 > [ +0.000011] snd_sof_amd_vangogh 0000:04:00.5: error: set pcm hw_params after resume > [ +0.000006] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_pcm_component_prepare on 0000:04:00.5: -22 > [...] > > A system reboot would be necessary to restore the speakers > functionality. > > However, by delaying a bit any host to DSP transmission right after > the firmware boot completed, the issue could not be reproduced anymore > and sound continued to work flawlessly even after performing thousands > of suspend/resume cycles. > > Introduce the post_fw_run_delay ACP quirk to allow providing the > aforementioned delay via the snd_sof_dsp_ops->post_fw_run() callback for > the affected devices. As per our understanding, Till ACP firmware starts responding to the driver's IPC messages, FW won't acquire the HW lock. Adding delay in post_fw_run() callback seems to not a correct solution, as there are no IPC messages will be sent from host till FW boot ready is received. Is fail to acquire the HW lock is for first host IPC message? > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> > --- > sound/soc/sof/amd/acp.c | 1 + > sound/soc/sof/amd/acp.h | 1 + > sound/soc/sof/amd/vangogh.c | 18 ++++++++++++++++++ > 3 files changed, 20 insertions(+) > > diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c > index 33648ff8b83365e76d7d90e52c2cb8f884a2fe72..9e13c96528be3371e063072513c118cfc8b93fe8 100644 > --- a/sound/soc/sof/amd/acp.c > +++ b/sound/soc/sof/amd/acp.c > @@ -27,6 +27,7 @@ MODULE_PARM_DESC(enable_fw_debug, "Enable Firmware debug"); > static struct acp_quirk_entry quirk_valve_galileo = { > .signed_fw_image = true, > .skip_iram_dram_size_mod = true, > + .post_fw_run_delay = true, > }; > > const struct dmi_system_id acp_sof_quirk_table[] = { > diff --git a/sound/soc/sof/amd/acp.h b/sound/soc/sof/amd/acp.h > index 800594440f73914e7b8ccaf86369ac686e1da630..2a19d82d6200223cdfccd49fbcf1b52968ae1230 100644 > --- a/sound/soc/sof/amd/acp.h > +++ b/sound/soc/sof/amd/acp.h > @@ -220,6 +220,7 @@ struct sof_amd_acp_desc { > struct acp_quirk_entry { > bool signed_fw_image; > bool skip_iram_dram_size_mod; > + bool post_fw_run_delay; > }; > > /* Common device data struct for ACP devices */ > diff --git a/sound/soc/sof/amd/vangogh.c b/sound/soc/sof/amd/vangogh.c > index 8e2672106ac60a22824836a944503a05616f8661..d5f1dddd43e72dd62b3d031130193e6125edf9df 100644 > --- a/sound/soc/sof/amd/vangogh.c > +++ b/sound/soc/sof/amd/vangogh.c > @@ -11,6 +11,7 @@ > * Hardware interface for Audio DSP on Vangogh platform > */ > > +#include <linux/delay.h> > #include <linux/platform_device.h> > #include <linux/module.h> > > @@ -136,6 +137,20 @@ static struct snd_soc_dai_driver vangogh_sof_dai[] = { > }, > }; > > +static int sof_vangogh_post_fw_run_delay(struct snd_sof_dev *sdev) > +{ > + /* > + * Resuming from suspend in some cases my cause the DSP firmware > + * to enter an unrecoverable faulty state. Delaying a bit any host > + * to DSP transmission right after firmware boot completion seems > + * to resolve the issue. > + */ > + if (!sdev->first_boot) > + usleep_range(100, 150); > + > + return 0; > +} > + > /* Vangogh ops */ > struct snd_sof_dsp_ops sof_vangogh_ops; > EXPORT_SYMBOL_NS(sof_vangogh_ops, "SND_SOC_SOF_AMD_COMMON"); > @@ -157,6 +172,9 @@ int sof_vangogh_ops_init(struct snd_sof_dev *sdev) > > if (quirks->signed_fw_image) > sof_vangogh_ops.load_firmware = acp_sof_load_signed_firmware; > + > + if (quirks->post_fw_run_delay) > + sof_vangogh_ops.post_fw_run = sof_vangogh_post_fw_run_delay; > } > > return 0; >

1 0

Re: [PATCH 3/4] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
by Mukunda,Vijendar 07 Feb '25

07 Feb '25

On 07/02/25 17:46, Cristian Ciocaltea wrote: > On 2/7/25 1:55 PM, Mukunda,Vijendar wrote: >> On 07/02/25 17:16, Cristian Ciocaltea wrote: >>> In some cases, e.g. during resuming from suspend, there is a possibility >>> that some IPC reply messages get received by the host while the DSP >>> firmware has not yet reached the complete boot state. >>> >>> Detect when this happens and do not attempt to process the unexpected >>> replies from DSP. Instead, provide proper debugging support. >> As per our understanding, before FW boot completion there won't >> be any IPC responses sent from Firmware. >> In this case, do we really need such a condition check? > During the suspend/resume stress testing I was able to get this kind of > messages, and that's the actual reason for introducing the verification. > > Also it doesn't seem to be uncommon, e.g. Intel HDA IPC also provides > similar checks. > Could you please share reference logs to know which IPC messages are being received before FW_READY message/FW boot complete? >>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> >>> --- >>> sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++------- >>> 1 file changed, 16 insertions(+), 7 deletions(-) >>> >>> diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c >>> index 5f371d9263f3bad507236ace95b7ef323c369187..12caefd08788595be8de03a863b88b5bbc15847d 100644 >>> --- a/sound/soc/sof/amd/acp-ipc.c >>> +++ b/sound/soc/sof/amd/acp-ipc.c >>> @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) >>> >>> if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) { >>> acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status)); >>> + >>> if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) { >>> snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status), >>> true); >>> @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) >>> >>> dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write); >>> if (dsp_ack) { >>> - spin_lock_irq(&sdev->ipc_lock); >>> - /* handle immediate reply from DSP core */ >>> - acp_dsp_ipc_get_reply(sdev); >>> - snd_sof_ipc_reply(sdev, 0); >>> - /* set the done bit */ >>> - acp_dsp_ipc_dsp_done(sdev); >>> - spin_unlock_irq(&sdev->ipc_lock); >>> + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) { >>> + spin_lock_irq(&sdev->ipc_lock); >>> + >>> + /* handle immediate reply from DSP core */ >>> + acp_dsp_ipc_get_reply(sdev); >>> + snd_sof_ipc_reply(sdev, 0); >>> + /* set the done bit */ >>> + acp_dsp_ipc_dsp_done(sdev); >>> + >>> + spin_unlock_irq(&sdev->ipc_lock); >>> + } else { >>> + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n", >>> + dsp_ack); >>> + } >>> + >>> ipc_irq = true; >>> } >>> >>>

1 0

Re: [PATCH 3/4] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
by Mukunda,Vijendar 07 Feb '25

07 Feb '25

On 07/02/25 17:16, Cristian Ciocaltea wrote: > In some cases, e.g. during resuming from suspend, there is a possibility > that some IPC reply messages get received by the host while the DSP > firmware has not yet reached the complete boot state. > > Detect when this happens and do not attempt to process the unexpected > replies from DSP. Instead, provide proper debugging support. As per our understanding, before FW boot completion there won't be any IPC responses sent from Firmware. In this case, do we really need such a condition check? > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> > --- > sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++------- > 1 file changed, 16 insertions(+), 7 deletions(-) > > diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c > index 5f371d9263f3bad507236ace95b7ef323c369187..12caefd08788595be8de03a863b88b5bbc15847d 100644 > --- a/sound/soc/sof/amd/acp-ipc.c > +++ b/sound/soc/sof/amd/acp-ipc.c > @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) > > if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) { > acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status)); > + > if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) { > snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status), > true); > @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context) > > dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write); > if (dsp_ack) { > - spin_lock_irq(&sdev->ipc_lock); > - /* handle immediate reply from DSP core */ > - acp_dsp_ipc_get_reply(sdev); > - snd_sof_ipc_reply(sdev, 0); > - /* set the done bit */ > - acp_dsp_ipc_dsp_done(sdev); > - spin_unlock_irq(&sdev->ipc_lock); > + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) { > + spin_lock_irq(&sdev->ipc_lock); > + > + /* handle immediate reply from DSP core */ > + acp_dsp_ipc_get_reply(sdev); > + snd_sof_ipc_reply(sdev, 0); > + /* set the done bit */ > + acp_dsp_ipc_dsp_done(sdev); > + > + spin_unlock_irq(&sdev->ipc_lock); > + } else { > + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n", > + dsp_ack); > + } > + > ipc_irq = true; > } > >

1 0

Re: [PATCH] ASoC: SOF: mediatek: Use str_on_off() helper function
by Mark Brown 06 Feb '25

06 Feb '25

On Tue, 04 Feb 2025 16:38:04 +0100, Thorsten Blum wrote: > Remove hard-coded strings by using the str_on_off() helper function. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: mediatek: Use str_on_off() helper function commit: 3f75771987f32a9f512c8944e70e343f8c6d71c1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH v2] ASoC: SOF: topology: Use krealloc_array() to replace krealloc()
by Mark Brown 05 Feb '25

05 Feb '25

On Fri, 17 Jan 2025 09:43:43 +0800, Zhang Heng wrote: > Use krealloc_array() to replace krealloc() with multiplication. > krealloc_array() has multiply overflow check, which will be safer. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: topology: Use krealloc_array() to replace krealloc() commit: a05143a8f713d9ae6abc41141dac52c66fca8b06 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0