Closed maaarghk closed 6 months ago
plbossart
commented
6 months ago can you provide the result of 'amixer -Dhw:0 info', this should list the components used by UCM.
Other than an UCM problem, I don't see any issues at the kernel level, the card is created and nothing looks suspicious.
maaarghk
commented
6 months ago There is a difference:
--- 6.8.9-amixer 2024-05-16 18:22:41.889448274 +0100
+++ 6.9.0-amixer 2024-05-16 18:46:41.309907768 +0100
@@ -1,5 +1,5 @@
Card hw:0 'sofsoundwire'/'Intel Soundwire SOF'
Mixer name : 'Intel Kabylake HDMI'
- Components : 'HDA:8086280b,80860101,00100000 cfg-spk:4 cfg-amp:2 hs:rt711 spk:rt1308 mic:rt715'
+ Components : 'HDA:8086280b,80860101,00100000 cfg-spk:4 cfg-amp:2 hs:rt711 spk:rt1308 mic:rt715-sdca'
Controls : 69
Simple ctrls : 42Attached dmesg at debug level for both versions. A relevant change seems that 6.9.0 has an extra log entry up top:
--- soundwire_debug_689.txt 2024-05-16 19:26:16.177883500 +0100
+++ soundwire_debug_690.txt 2024-05-16 19:27:04.017938631 +0100
@@ -1,6 +1,7 @@
snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
snd_hda_intel:azx_probe: snd_hda_intel 0000:00:1f.3: HDAudio driver not selected, aborting probe
snd_soc_skl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
+snd_soc_avs 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
sof-audio-pci-intel-cnl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
snd_sof_pci:sof_pci_probe: sof-audio-pci-intel-cnl 0000:00:1f.3: PCI DSP detected
sof-audio-pci-intel-cnl 0000:00:1f.3: enabling device (0000 -> 0002)Many changes follow but not sure how to interpret this.
plbossart
commented
6 months ago The issue is probably the additional 'sdca' field and this looks like a duplicate of https://github.com/thesofproject/linux/issues/4834, reported by @ujfalusi and fixed by @bardliao
Can you try to add this patch: bee2fe44679f1e6a5332d7f78587ccca4109919f ("SoC: Intel: sof_sdw: use generic rtd_init function for Realtek SDW DMICs")
maaarghk
commented
6 months ago Ok, that wouldn't apply cleanly but I applied the below version (line numbers changed) to v6.9 of the kernel and the bug is resolved.
There is still a valid issue report to be answered here, albeit to do with process rather than a regression:
Fixes <sha>" commit message - that code with a known, fixed, regression remained on 6.9 branch throughout the 6 release candidates that followedCould you please make sure this patch gets in to 6.9.2 so that users with this hardware do not need to compile their own kernel?
From bee2fe44679f1e6a5332d7f78587ccca4109919f Mon Sep 17 00:00:00 2001
From: Bard Liao <yung-chuan.liao@linux.intel.com>
Date: Tue, 26 Mar 2024 11:04:19 -0500
Subject: [PATCH] ASoC: Intel: sof_sdw: use generic rtd_init function for
Realtek SDW DMICs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The only thing that the rt_xxx_rtd_init() functions do is to set
card->components. And we can set card->components with name_prefix
as rt712_sdca_dmic_rtd_init() does.
And sof_sdw_rtd_init() will always select the first dai with the
given dai->name from codec_info_list[]. Unfortunately, we have
different codecs with the same dai name. For example, dai name of
rt715 and rt715-sdca are both "rt715-aif2". Using a generic rtd_init
allow sof_sdw_rtd_init() run the rtd_init() callback from a similar
codec dai.
Fixes: 8266c73126b7 ("ASoC: Intel: sof_sdw: add common sdw dai link init")
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://msgid.link/r/20240326160429.13560-25-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/intel/boards/Makefile | 1 +
sound/soc/intel/boards/sof_sdw.c | 12 +++---
sound/soc/intel/boards/sof_sdw_common.h | 1 +
sound/soc/intel/boards/sof_sdw_rt_dmic.c | 52 ++++++++++++++++++++++++
4 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 sound/soc/intel/boards/sof_sdw_rt_dmic.c
diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile
index bbf796a5f7ba81..08cfd4baecdd72 100644
--- a/sound/soc/intel/boards/Makefile
+++ b/sound/soc/intel/boards/Makefile
@@ -42,6 +42,7 @@ snd-soc-sof-sdw-objs += sof_sdw.o \
sof_sdw_rt711.o sof_sdw_rt_sdca_jack_common.o \
sof_sdw_rt712_sdca.o sof_sdw_rt715.o \
sof_sdw_rt715_sdca.o sof_sdw_rt722_sdca.o \
+ sof_sdw_rt_dmic.o \
sof_sdw_cs42l42.o sof_sdw_cs42l43.o \
sof_sdw_cs_amp.o \
sof_sdw_dmic.o \
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index 3e6a758c98ab49..0e376cb0ce0b28 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -730,7 +749,7 @@
.dai_name = "rt712-sdca-dmic-aif1",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt712_sdca_dmic_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
@@ -760,7 +779,7 @@
.dai_name = "rt712-sdca-dmic-aif1",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt712_sdca_dmic_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
@@ -822,7 +841,7 @@
.dai_name = "rt715-aif2",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt715_sdca_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
@@ -837,7 +856,7 @@
.dai_name = "rt715-aif2",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt715_sdca_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
@@ -852,7 +871,7 @@
.dai_name = "rt715-aif2",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt715_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
@@ -867,7 +886,7 @@
.dai_name = "rt715-aif2",
.dai_type = SOF_SDW_DAI_TYPE_MIC,
.dailink = {SDW_UNUSED_DAI_ID, SDW_DMIC_DAI_ID},
- .rtd_init = rt715_rtd_init,
+ .rtd_init = rt_dmic_rtd_init,
},
},
.dai_num = 1,
diff --git a/sound/soc/intel/boards/sof_sdw_common.h b/sound/soc/intel/boards/sof_sdw_common.h
index e21ef79126b298..decaed97fa74ff 100644
--- a/sound/soc/intel/boards/sof_sdw_common.h
+++ b/sound/soc/intel/boards/sof_sdw_common.h
@@ -197,6 +197,7 @@ int rt712_sdca_dmic_rtd_init(struct snd_soc_pcm_runtime *rtd);
int rt712_spk_rtd_init(struct snd_soc_pcm_runtime *rtd);
int rt715_rtd_init(struct snd_soc_pcm_runtime *rtd);
int rt715_sdca_rtd_init(struct snd_soc_pcm_runtime *rtd);
+int rt_dmic_rtd_init(struct snd_soc_pcm_runtime *rtd);
int rt_amp_spk_rtd_init(struct snd_soc_pcm_runtime *rtd);
int rt_sdca_jack_rtd_init(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/intel/boards/sof_sdw_rt_dmic.c b/sound/soc/intel/boards/sof_sdw_rt_dmic.c
new file mode 100644
index 00000000000000..9091f5b5c64845
--- /dev/null
+++ b/sound/soc/intel/boards/sof_sdw_rt_dmic.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2024 Intel Corporation
+
+/*
+ * sof_sdw_rt_dmic - Helpers to handle Realtek SDW DMIC from generic machine driver
+ */
+
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <sound/soc.h>
+#include <sound/soc-acpi.h>
+#include "sof_board_helpers.h"
+#include "sof_sdw_common.h"
+
+static const char * const dmics[] = {
+ "rt715",
+ "rt712-sdca-dmic",
+};
+
+int rt_dmic_rtd_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_card *card = rtd->card;
+ struct snd_soc_component *component;
+ struct snd_soc_dai *codec_dai;
+ char *mic_name;
+
+ codec_dai = get_codec_dai_by_name(rtd, dmics, ARRAY_SIZE(dmics));
+ if (!codec_dai)
+ return -EINVAL;
+
+ component = codec_dai->component;
+
+ /*
+ * rt715-sdca (aka rt714) is a special case that uses different name in card->components
+ * and component->name_prefix.
+ */
+ if (!strcmp(component->name_prefix, "rt714"))
+ mic_name = devm_kasprintf(card->dev, GFP_KERNEL, "rt715-sdca");
+ else
+ mic_name = devm_kasprintf(card->dev, GFP_KERNEL, "%s", component->name_prefix);
+
+ card->components = devm_kasprintf(card->dev, GFP_KERNEL,
+ "%s mic:%s", card->components,
+ mic_name);
+ if (!card->components)
+ return -ENOMEM;
+
+ dev_dbg(card->dev, "card->components: %s\n", card->components);
+
+ return 0;
+}
+MODULE_IMPORT_NS(SND_SOC_INTEL_SOF_BOARD_HELPERS);
bardliao
commented
6 months ago Ok, that wouldn't apply cleanly but I applied the below version (line numbers changed) to v6.9 of the kernel and the bug is resolved.
@maaarghk What kernel version did you try to apply? It can apply cleanly to Linux 6.9-rc1, and the commit has Fixes: 8266c73126b7 ("ASoC: Intel: sof_sdw: add common sdw dai link init") tag. So, I assume that kernel backport team will handle it?
maaarghk
commented
6 months ago Linux 6.9.0, which had other changes to sof in e.g. Linux 6.9-rc2, -rc3, -rc4, -rc5. The question is why this patch was not submitted for Linux 6.9-rc2 - how would the kernel backport team be aware that a commit added in March 24 fixes a bug currently on 6.9.0 / 6.9.1? Should I raise this bug on a kernel bug tracker so that someone else does it, or. is your team able to submit the patch for 6.9.2?
plbossart
commented
6 months ago The SOF team does not send patches directly to Linus, the patches go through two maintainers for ASoC and ALSA respectively. It was probably an oversight that the Fixes tag was not detected in the ~200 patches we submitted in the last cycle. @ujfalusi will you send the patch to linux-stable?
ujfalusi
commented
6 months ago Linux 6.9.0, which had other changes to sof in e.g. Linux 6.9-rc2, -rc3, -rc4, -rc5. The question is why this patch was not submitted for Linux 6.9-rc2 - how would the kernel backport team be aware that a commit added in March 24 fixes a bug currently on 6.9.0 / 6.9.1?
The fix patch was part of a bigger series sent for 6.10: https://lore.kernel.org/linux-sound/20240326160429.13560-1-pierre-louis.bossart@linux.intel.com/ Normally this works as the ASoC maintainer's automation takes care of sorting patches for the current cycle or for next: When a patch is applied and it has Fixes tag and the SHA is in mainline then it is queued to the current cycle as fix and sent for the next -rc. What might have happened is that when the SOF patches got merged, the sound updates not yet landed to mainline, thus the fix is not picked up by automation and it did not made it to the 6.9 cycle. The odds are small for this to happen but it did. The patches from https://github.com/thesofproject/linux/pull/4835 should have been a separate series specifically calling for 6.9 (ASoC maintainer usually points out that no need to mention this as the automation takes care of things). We should have followed up that it lands in mainline.
Should I raise this bug on a kernel bug tracker so that someone else does it, or. is your team able to submit the patch for 6.9.2?
The fix is in mainline now and normally based on the Fixes tag's SHA it is going to be picked for stable by the kernel.org automation, which for some reason still did not happened. In any case, I will send a backport patch to stable in hope that it will land in 6.9.2
We are really sorry for this to happen and the caused frustration. We will tune our processes to be able to better catch such fallouts.
ujfalusi
commented
6 months ago Stable backport patch: https://lore.kernel.org/stable/20240521072451.5488-1-peter.ujfalusi@linux.intel.com/T/#u
ujfalusi
commented
6 months ago @maaarghk, the fix will be included in 6.9.2: https://lore.kernel.org/stable/20240523130330.738992207@linuxfoundation.org/T/#u
Can you check and confirm when the updated kernel is available? Thank you.
maaarghk
commented
6 months ago hey Péter,
We are really sorry for this to happen and the caused frustration. We will tune our processes to be able to better catch such fallouts.
That's alright, I appreciate the transparency. If this had happened with a closed source driver it would have been a lot more painful.
the fix will be included in 6.9.2:
I just upgraded to 6.9.2 and everything appears to be good, thanks.
I don't get any audio output on kernel 6.9.0 from the Speaker output. I did not test the Jack Out or HDMI so can't say whether those work.
I'm recording it in this particular repository because I can restart the system with a different kernel version but same alsa, ucm, pipewire, firmware versions etc. and the 6.8.9 kernel still works.
pipewire 1.0.6 alsa-ucm-conf 1.2.11 sof-firmware 2024.03
Non-verbose logs are the same on both versions:
Aplay device list output same on both kernel versions:
There is a different in how Pipewire detects things. On 6.8.9 I have two profiles, Pro Audio and "Play HiFi Quality Music". The HiFi one is the default, and "Speaker" works normally as an output. If I switch to the "Pro Audio" profile, I can get audio output by selecting "comet lake pch cavs pro 2" as the output.
On 6.9.0 the "Play HiFi Quality Music" profile does not appear, just one called "Stereo Audio" or something like that. The outputs under Pro Audio appear to be the same but I no longer get audio when selecting Pro 2.
I also notice that running
speaker-test -Dhw:0,2 -c2when HiFi is selected on 6.8.9 gives me a "Device or resource is busy" error unless I change pipewire profile to "Off". (I may be holding it wrong but that doesn't actually produce sound on 6.8.9). Either way -on 6.9.0, running the same command does not give me an error, it just proceeds to attempt to play audio, regardless of what profile is selected.Hopefully this is enough to get on with but - if you don't have any test hardware of this model - let me know how to get any other info you need.