hirnschmalz
commented
3 years ago I can confirm this, same issue here on my HP Spectre x360 13-aw2777ng
Closed aigilea closed 3 years ago
hirnschmalz
commented
3 years ago I can confirm this, same issue here on my HP Spectre x360 13-aw2777ng
juimonen
commented
3 years ago @bardliao @libinyang this seems to be soundwire device... any idea why we don't have pcm devices?
bardliao
commented
3 years ago sof-audio-pci 0000:00:1f.3: No SoundWire machine driver foundThe issue is that SOF driver can't find a suitable machine driver for this device. The driver will look up eg. snd_soc_acpi_intel_cml_sdw_machines[] to find a suitable machine driver.
So we have to add your device codec information to the corresponding acpi match table.
Please add below to /etc/modprobe.d/sof-dyndbg.conf and attach the whole dmesg output here. Create one if you don't have this file on your device.
options soundwire_bus dyndbg=+p
options soundwire_intel dyndbg=+pAnd, please show me the result of lspci | grep '00:1f.3'
Thanks
aigilea
commented
3 years ago Attaching full dmesg with dyndbg.
lspci | grep '00:1f.3'
0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)Here's my output of lspci | grep '00:1f.3'
0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)and my dmesg.
bardliao
commented
3 years ago Attaching full dmesg with dyndbg.
[ 6.339077] soundwire sdw-master-0: Slave attached, programming device number
[ 6.339280] soundwire sdw-master-0: SDW Slave Addr: 20025d071100
[ 6.339281] soundwire sdw-master-0: SDW Slave class_id 0, part_id 711, mfg_id 25d, unique_id 0, version 2
[ 6.339306] soundwire sdw-master-0: Slave Entry not found
[ 6.339504] soundwire sdw-master-0: SDW Slave Addr: 20025d071100
[ 6.339506] soundwire sdw-master-0: SDW Slave class_id 0, part_id 711, mfg_id 25d, unique_id 0, version 2
[ 6.339583] soundwire sdw-master-1: Slave attached, programming device number
[ 6.339795] soundwire sdw-master-0: No more devices to enumerate
[ 6.339800] soundwire sdw-master-1: SDW Slave Addr: 20025d130800
[ 6.339806] soundwire sdw-master-1: SDW Slave class_id 0, part_id 1308, mfg_id 25d, unique_id 0, version 2
[ 6.339850] soundwire sdw-master-1: Slave Entry not foundFrom above, the codecs on your device is rt711 and rt1308. But from below, your codec's information is not listed in the acpi table.
[ 6.231331] soundwire sdw-master-0: SDW Slave Addr: 10025d070100
[ 6.231334] soundwire sdw-master-0: SDW Slave class_id 0, part_id 701, mfg_id 25d, unique_id 0, version 1
[ 6.231350] soundwire sdw-master-0: SDW Slave Addr: 10025d070000
[ 6.231352] soundwire sdw-master-0: SDW Slave class_id 0, part_id 700, mfg_id 25d, unique_id 0, version 1
[ 6.231401] soundwire sdw-master-0: SDW Slave Addr: 10025d070000
[ 6.231402] soundwire sdw-master-0: SDW Slave class_id 0, part_id 700, mfg_id 25d, unique_id 0, version 1
[ 6.231405] soundwire sdw-master-0: SDW Slave Addr: 10025d070100
[ 6.231407] soundwire sdw-master-0: SDW Slave class_id 0, part_id 701, mfg_id 25d, unique_id 0, version 1
[ 6.231507] soundwire sdw-master-1: SDW Slave Addr: 110025d070100
[ 6.231508] soundwire sdw-master-1: SDW Slave class_id 0, part_id 701, mfg_id 25d, unique_id 0, version 1
[ 6.231518] soundwire sdw-master-1: SDW Slave Addr: 110025d070000
[ 6.231520] soundwire sdw-master-1: SDW Slave class_id 0, part_id 700, mfg_id 25d, unique_id 0, version 1
[ 6.231575] soundwire sdw-master-1: SDW Slave Addr: 110025d070000
[ 6.231577] soundwire sdw-master-1: SDW Slave class_id 0, part_id 700, mfg_id 25d, unique_id 0, version 1
[ 6.231585] soundwire sdw-master-1: SDW Slave Addr: 110025d070100
[ 6.231587] soundwire sdw-master-1: SDW Slave class_id 0, part_id 701, mfg_id 25d, unique_id 0, version 1So, we have to add the codec information to BIOS at first. We need to figure out who can help on it. @mengdonglin
lspci | grep '00:1f.3'0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
It is a TGL device and the match table is snd_soc_acpi_intel_tgl_sdw_machines[]. Looking at the table, we don't have a matched table for your device (rt711 on link 0 and 1 rt1308 on link 1), but fortunately, we have a similar configuration tgl_rvp. We should be able to enable SoundWire on your device with slight modification. Below patch may help, but I have no chance to test it.
diff --git a/sound/soc/intel/common/soc-acpi-intel-tgl-match.c b/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
index e3ddbf05bf72..529f40868ae9 100644
--- a/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
+++ b/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
@@ -205,6 +205,20 @@ static const struct snd_soc_acpi_link_adr tgl_rvp[] = {
{}
};
+static const struct snd_soc_acpi_link_adr tgl_rt711_rt1308[] = {
+ {
+ .mask = BIT(0),
+ .num_adr = ARRAY_SIZE(rt711_0_adr),
+ .adr_d = rt711_0_adr,
+ },
+ {
+ .mask = BIT(1),
+ .num_adr = ARRAY_SIZE(rt1308_1_single_adr),
+ .adr_d = rt1308_1_single_adr,
+ },
+ {}
+};
+
static const struct snd_soc_acpi_link_adr tgl_chromebook_base[] = {
{
.mask = BIT(0),
@@ -401,6 +415,12 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_tgl_sdw_machines[] = {
.drv_name = "sof_sdw",
.sof_tplg_filename = "sof-tgl-rt5682.tplg",
},
+ {
+ .link_mask = 0x3, /* rt711 on link 0 and 1 rt1308s on link 1 */
+ .links = tgl_rt711_rt1308,
+ .drv_name = "sof_sdw",
+ .sof_tplg_filename = "sof-tgl-rt711-rt1308.tplg",
+ },
{},
};
EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_tgl_sdw_machines);But, again, you have to fix the BIOS issue first. Alternative way is to add acpi table by yourself.
You can follow the guide to add additional acpi table.
A reference asl file is rtk_sdw_i2c.asl.
You don't need the I2C part. What you need is to add rt711 and rt1308 address into Scope (_SB.PC00.HDAS.SNDW)
Scope (_SB.PC00.HDAS.SNDW) {
Device (RTK0) // RT711 on link0
{
Name (_ADR, 0x000020025D071100) // _ADR: Address
}
Device (RTK1) // RT1308 on link1
{
Name (_ADR, 0x000120025D130800) // _ADR: Address
}
There's some progress.
Now it looks better in dmesg, SOF initializes without errors, but the result is even stranger:
ls /dev/snd
seq timerI'm attaching the new dmesg and just in case dsdt.
upd. I've re-checked if maybe I've somehow messed the particular kernel build up, but no, removing just the acpi patch turns everything back to errors in dmesg and a few files in /dev/snd with the same patched kernel.
plbossart
commented
3 years ago @aigilea thanks for testing. Can you try to add dynamic debug to sof_sdw ? when the probe remains silent, it's usually that the machine driver probe fails, and unfortunately we have no way to report this at a higher level.
plbossart
commented
3 years ago @bardliao I am wondering if we shouldn't add a hack where we use the adr for 701 for either RT711 or RT1308. The BIOS is broken, and if we don't get a fix we should have an indirection to the 'right' devices.
aigilea
commented
3 years ago @plbossart I've tried enabling dyndbg for sof_sdw.c, sof_sdw and sof_sdw* (but forgot to save that dmesg, I can redo this one if it may be useful). I haven't found any new information in dmesgs. I've enabled dyndbg via kernel options, this morning it worked that way with atkdb.c so I guess it's ok. If it's not, I can redo any other way.
plbossart
commented
3 years ago @aigilea to be honest none of us on the Intel Linux team knew of the existence of HP devices with SoundWire, but that's indeed a real product. We can't expect everyone to override the DSDT, that's too invasive.
if you have spare cycles, can you try https://github.com/thesofproject/linux/pull/2701 without the DSDT override? It should at least find the right devices but may fail later on.
I still need to confirm if there are one or two amplifiers on the link1, in the first case we are missing a topology configuration for mono amplifier.
plbossart
commented
3 years ago I've enabled dyndbg via kernel options, this morning it worked that way with atkdb.c so I guess it's ok. If it's not, I can redo any other way.
You can enable dynamic debug by copying this file ddebug.txt as /etc/modprobe.d/sof-dyndbg.conf (reboot required after adding the file)/
aigilea
commented
3 years ago @plbossart should I keep the bardliao's patch to soc-acpi-intel-tgl-match.c when applying your commit?
plbossart
commented
3 years ago @plbossart should I keep the bardliao's patch to soc-acpi-intel-tgl-match.c when applying your commit?
no, you'd need to add this on top of your kernel without Bard's change. This is a proof of concept, so bear with me if there are some issues left and right. Only trying to make sure it's easier in the end for all users of this platform.
aigilea
commented
3 years ago @plbossart I've bumped into build problems with dev_dbg calls and fixed them before I've seen you've updated the patch. I now see another difference in the latest patch with entry ordering in snd_soc_acpi_intel_tgl_sdw_machines, but it shouldn't affect me, right?
Anyway, it doesn't work out of the box, but it shows more information. Here the dmesg with the first ACPI patch and your dyndbg config, here's the dmesg with your patch.
plbossart
commented
3 years ago thanks @aigilea I think there's something missing when the probe fails. I'll try locally on a device I have with similar BIOS issues, stay tuned. thanks!
bardliao
commented
3 years ago @bardliao I am wondering if we shouldn't add a hack where we use the adr for 701 for either RT711 or RT1308. The BIOS is broken, and if we don't get a fix we should have an indirection to the 'right' devices.
Right, we should fix the adr issue on BIOS. The hack or DSDT overwrite should only be used for testing on local machines before we get a proper BIOS.
bardliao
commented
3 years ago @aigilea Could you add options snd_soc_core dyndbg=+p to /etc/modprobe.d/sof-dyndbg.conf? It can help us to get more information why sound card is not probed.
aigilea
commented
3 years ago @bardliao here's dmesg with this option from the kernel with acpi overlay.
RanderWang
commented
3 years ago @bardliao I am wondering if we shouldn't add a hack where we use the adr for 701 for either RT711 or RT1308. The BIOS is broken, and if we don't get a fix we should have an indirection to the 'right' devices.
Right, we should fix the adr issue on BIOS. The hack or DSDT overwrite should only be used for testing on local machines before we get a proper BIOS.
RanderWang
commented
3 years ago @kv2019i @libinyang please check this on ADL and report a bug to BIOS team. It is too late to report it after PV.
bardliao
commented
3 years ago @aigilea I assume you have added options snd_sof dyndbg=+p to /etc/modprobe.d/sof-dyndbg.conf, but I didn't see any log from sof_sdw.c. So I am wondering if CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is selected in your .config file. Could you check if you can see CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m or CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=y in your .config file?
If not, please select SoundWire generic machine driver by make menuconfig.
Device Drivers ---> Sound card support ---> Advanced Linux Sound Architecture ---> ALSA for SoC audio support ---> Intel Machine drivers --> < > SoundWire generic machine driver@bardliao
cat /etc/modprobe.d/sof-dyndbg.conf |grep "snd_sof"
options snd_sof_intel_byt dyndbg=+p
options snd_sof_intel_bdw dyndbg=+p
options snd_sof_intel_ipc dyndbg=+p
options snd_sof_intel_hda_common dyndbg=+p
options snd_sof_intel_hda dyndbg=+p
options snd_sof dyndbg=+p
options snd_sof_pci dyndbg=+p
options snd_sof_acpi dyndbg=+p
options snd_sof_of dyndbg=+p
options snd_sof_nocodec dyndbg=+pThe config I use is from the ubuntu's build of 5.11-rc4 and you're right about the module
cat /boot/config-`uname -r`|grep -c CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH
0I have no such item on the menu, but sound/soc/intel/boards/Makefile handles it, so I'll just add it to the config.
Or should I re-try with the latest kernel from the git?
upd. Ok, that was not a good idea, but I've found that the "SoundWire generic machine driver" menu item is hidden by "Use more user friendly long card names", so rebuilding again now.
bardliao
commented
3 years ago @aigilea You can git clone https://github.com/thesofproject/kconfig and run ../kconfig-sof-default.sh in your kernel tree. It should generate a kconfig for you.
aigilea
commented
3 years ago @bardliao now there are messages from sof_sdw in dmesg. No pcms though.
bardliao
commented
3 years ago [ 6.276960] sof-audio-pci 0000:00:1f.3: found 711 at link 0
[ 6.276963] sof-audio-pci 0000:00:1f.3: found 1308 at link 1
[ 6.276964] sof-audio-pci 0000:00:1f.3: found 1308 at link 1
...
[ 6.382122] sof_sdw sof_sdw: ASoC: codec component sdw:1:25d:1308:0:0 not found for link SDW1-Playback
[ 6.382138] sof_sdw sof_sdw: snd_soc_register_card failed -517The driver found rt1308 twice therefore is_unique_device return false while it is supposed to be true. I guess you may do acpi-add twice or there are two rt1308 adr in your .asl file. You can try to remove one of them or add the following hack in sof_sdw.c
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index 6d0d6ef711e0..ac9b69ce43b3 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -484,6 +484,7 @@ static bool is_unique_device(const struct snd_soc_acpi_link_adr *link,
int index_in_link
)
{
+#if 0
int i;
for (i = 0; i < link->num_adr; i++) {
@@ -507,7 +508,7 @@ static bool is_unique_device(const struct snd_soc_acpi_link_adr *link,
class_id == class1_id)
return false;
}
-
+#endif
return true;
}@bardliao that's strange. I'm using only your scripts to manage ACPI overrides.
ls /usr/lib/firmware/acpi-upgrades/
dsdtmod.amlcat ./acpi/dsdtmod.asl
DefinitionBlock("", "SSDT", 2, "SOF", "x360tgl", 0x1000)
{
External(\_SB.PC00.HDAS.SNDW, DeviceObj)
Scope (_SB.PC00.HDAS.SNDW) {
Device (RTK0) // RT711 on link0
{
Name (_ADR, 0x000020025D071100) // _ADR: Address
}
Device (RTK1) // RT1308 on link1
{
Name (_ADR, 0x000120025D130800) // _ADR: Address
}
}
}Building the patched kernel now.
aigilea
commented
3 years ago @bardliao ok, new dmesg in a nutshell:
[ 6.382857] sof-audio-pci 0000:00:1f.3: loading topology:intel/sof-tplg/sof-tgl-rt711-rt1308.tplg
[ 6.383139] sof-audio-pci 0000:00:1f.3: Direct firmware load for intel/sof-tplg/sof-tgl-rt711-rt1308.tplg failed with error -2
[ 6.383141] sof-audio-pci 0000:00:1f.3: error: tplg request firmware intel/sof-tplg/sof-tgl-rt711-rt1308.tplg failed err: -2
[ 6.383144] sof-audio-pci 0000:00:1f.3: error: failed to load DSP topology -2
[ 6.383145] sof-audio-pci 0000:00:1f.3: ASoC: error at snd_soc_component_probe on 0000:00:1f.3: -2
[ 6.383146] sof-audio-pci 0000:00:1f.3: ASoC: failed to probe component -2
[ 6.383151] sof_sdw sof_sdw: ASoC: failed to instantiate card -2
[ 6.383196] sof_sdw sof_sdw: snd_soc_register_card failed -2
[ 6.383199] sof_sdw: probe of sof_sdw failed with error -2And indeed, no such topology in 1.6.1.
bardliao
commented
3 years ago @aigilea Please rename sof-tgl-rt711-rt1308-2ch.tplg to sof-tgl-rt711-rt1308.tplg and see what happen.
aigilea
commented
3 years ago @bardliao new dmesg, a lot of new messages, but still failed in the end.
plbossart
commented
3 years ago @aigilea I updated https://github.com/thesofproject/linux/pull/2701. I can't test it directly so I asked my colleague @RanderWang to take a look tonight. With the update (it's a complicated work-around) you shouldn't need any ACPI initrd updates.
For the topology file, we have a problem with the dmic configuration, today it needs a manual rename of the topology file with the -2ch suffix removed. We need to automate this. In case you don't have the file, here it is (unzip and install in /lib/firmware/intel/sof-tplg/sof-tgl-rt711-rt1308.tplg)
aigilea
commented
3 years ago @plbossart I've copied the topology file as follows before last acpi attempt earlier today:
cp /usr/lib/firmware/intel/sof-tplg-v1.6.1/sof-tgl-rt711-rt1308-2ch.tplg /usr/lib/firmware/intel/sof-tplg-v1.6.1/sof-tgl-rt711-rt1308.tplg
workaround currently fails with
[ 6.489261] sof-audio-pci 0000:00:1f.3: SoundWire machine driver sof_sdw topology sof-tgl-rt711-rt1308.tplg
[ 6.489263] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 4
[ 6.489272] sof-audio-pci 0000:00:1f.3: loading firmware
[ 6.489396] sof-audio-pci 0000:00:1f.3: Direct firmware load for intel/sof/(null) failed with error -2
[ 6.489399] sof-audio-pci 0000:00:1f.3: error: request firmware intel/sof/(null) failed err: -2
[ 6.489437] sof-audio-pci 0000:00:1f.3: error: failed to load DSP firmware -2(full dmesg)
upd.
I've copied sof-tgl.ri to (null) to work this particular glitch around and now I'm in the same spot as with acpi override.
dmesg
bardliao
commented
3 years ago @aigilea Please apply https://github.com/thesofproject/linux/pull/2705 and add options snd_soc_sof_sdw dyndbg=+p to sof-dyndbg.conf.
You will also need to add a quirk for your device, like.
https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/boards/sof_sdw.c#L80
I believe that you will need SOF_SDW_PCH_DMIC and probably SOF_RT711_JD_SRC_JD2
RanderWang
commented
3 years ago @aigilea Please apply #2705 and add
options snd_soc_sof_sdw dyndbg=+pto sof-dyndbg.conf. You will also need to add a quirk for your device, like. https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/boards/sof_sdw.c#L80 I believe that you will needSOF_SDW_PCH_DMICand probablySOF_RT711_JD_SRC_JD2
yes, you need some code like
{
.callback = sof_sdw_quirk_cb,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP xxx"),
DMI_MATCH(DMI_PRODUCT_NAME, "xxxxx"),
},
.driver_data = (void *)(SOF_SDW_TGL_HDMI | SOF_SDW_PCH_DMIC
SOF_RT711_JD_SRC_JD2),
},you can use " dmidecode | grep vendor " to get VENDOR, and "dmidecode | grep Product" for PRODUCT NAME
plbossart
commented
3 years ago @aigilea if you can run alsa-info and give us the pointer that will give us all the information needed to add a quirk.
Still, @bardliao @RanderWang we should start thinking of stopping this endless addition of quirks. the PCH_DMIC info can come from NHLT tables, and the jack is always JD2. The HDMI could be added just by checking the chipset. there's nothing that really forces us to use a quirk here
bardliao
commented
3 years ago the jack is always JD2.
I am not sure if it is true. SOF_RT711_JD_SRC_JD1 is the default value now and we do have .driver_data = (void *)(SOF_RT711_JD_SRC_JD1 for TGL RVP. But I agree that we should at least treat JD2 as the default.
aigilea
commented
3 years ago @bardliao @RanderWang @plbossart so here's my dmidecode result. I've taken the "workaround" kernel as a base and added the following block to sof_sdw_quirk_table[] just before {}:
{
.callback = sof_sdw_quirk_cb,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
DMI_MATCH(DMI_PRODUCT_NAME, "8709"),
},
.driver_data = (void *)(SOF_SDW_TGL_HDMI | SOF_SDW_PCH_DMIC |
SOF_RT711_JD_SRC_JD2),
},Still it wanted to load intel/sof/(null) as firmware and sof-tgl-rt711-rt1308.tplg as topology, so I've copied sof-tgl.ri and sof-tgl-rt711-rt1308-2ch.tplg again to let it continue.
I've also applied #2705 and added dyndbg for snd_soc_sof_sdw. Here's the resulting dmesg.txt and alsa-info just in case.
bardliao
commented
3 years ago @aigilea You didn't set quirk successfully.
[ 6.302412] sof_sdw sof_sdw: Entry mc_probe
[ 6.302418] sof_sdw sof_sdw: quirk realtek,jack-detect-source 1I am not familiar with, but I think the DMI_PRODUCT_NAME is HP Spectre x360 Convertible 13-aw2xxx/8709 or HP Spectre x360 Convertible 13-aw2xxx. Could you try it? Or remove DMI_MATCH(DMI_PRODUCT_NAME, "8709"), for now.
You should see below if you set quirk properly.
quirk realtek,jack-detect-source 2
quirk SOF_SDW_TGL_HDMI enabled
quirk SOF_SDW_PCH_DMIC enabled@bardliao the correct one was HP Spectre x360 Convertible 13-aw2xxx and that resulted in a progress:
However speakers and microphones are still not usable. Speakers are visible in alsamixer, but they are get muted every time pulseaudio starts and no sink is created. dmesg, pulseaudio -v, pactl list cards, pactl list sinks, aplay -l, aplay -L
ls /dev/snd
by-path controlC0 hwC0D2 pcmC0D0p pcmC0D1c pcmC0D2p pcmC0D3c pcmC0D4c pcmC0D5p pcmC0D6p pcmC0D7p pcmC0D8p seq timerupd. Sorry, dmesg was truncated, reuploading it.
bardliao
commented
3 years ago @aigilea I think the missing part is UCM. @libinyang Can you help on it?
plbossart
commented
3 years ago @aigilea ok, that's good progress then, rather encouraging. Can you share the updated quirk, I will add it to the default and restrict the hacks I did to your machine.
For UCM to work, we need to report the number of microphones to userspace (UCM) via an ALSA info configuration string. We will need additional patches in the machine driver to make this work, and then we need additional patches to UCM.
aigilea
commented
3 years ago @plbossart
{
.callback = sof_sdw_quirk_cb,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP Spectre x360 Convertible 13-aw2xxx"),
},
.driver_data = (void *)(SOF_SDW_TGL_HDMI | SOF_SDW_PCH_DMIC |
SOF_RT711_JD_SRC_JD2),
},@aigilea I updated PR #2701 with your quirk, and added autodetection for the DMIC. You should now be able to run this directly (the sof-topology name now needs to be sof-tgl-rt711-rt1308-2ch.tplg, no rename)
If you try and type : amixer -Dhw:0 info, you should now see a cfg-dmics string that is needed by UCM. Can you confirm you see it? If yes, we can move on to the UCM fixes, should be rather easy.
Thanks for your help!
aigilea
commented
3 years ago @plbossart I've had to apply 2ad1b7a5c3624d265b487dc7a2fbf52a48f6ff71 first.
Now it properly chooses sof-tgl-rt711-rt1308-2ch.tplg and intel/sof/sof-tgl.ri but fails after that with sof_sdw sof_sdw: snd_soc_register_card failed -517 (dmesg).
sound/soc/sof/intel/hda.c have changed a lot since 5.11-rc4, should I maybe just build the sdw/bios-workaround branch from your repo?
plbossart
commented
3 years ago @aigilea yes, please start from my branch, I don't understand some of the errors reported.
aigilea
commented
3 years ago @plbossart with these 38dc8f0688634a6596aeb11f2656a9fef49772f9 1ffe680eb0fefcee7475b42ddfe329721cc9f42a reverted everything back to normal. I'll rebuild with both link_id check and quirk table check. I mean with the broken bios, isn't the link_id the only way for slave drivers to decide which driver attaches to which slave?
btw, it's the 2ad1b7a5c3624d265b487dc7a2fbf52a48f6ff71 that fixed (null) fw name.
plbossart
commented
3 years ago Thanks @aigilea I added a better DMI quirk with the link check re-added.
I have this commit 2ad1b7a in my branch already, that should work fine.
plbossart
commented
3 years ago @aigilea looking at UCM now, what do you see with arecord -l ?
I need DMIC PCM device, should be hw:0,3 for DMIC and hw:0,4 for the DMIC16kHz based on topology but better check. thanks!
aigilea
commented
3 years ago @plbossart yes, that was the cause, condition like (id->part_id == 0x701 && (slave->bus->link_id != X || !dmi_id)) works ok.
I've checked it on the previous kernel as it was much faster to build, from now on I'm switching to your branch.
amixer -Dhw:0 info
Card hw:0 'sofsoundwire'/'Intel Soundwire SOF'
Mixer name : 'Intel Tigerlake HDMI'
Components : 'HDA:80862812,80860101,00100000 cfg-spk:2 cfg-amp:1 cfg-dmics:2 hs:rt711 spk:rt1308'
Controls : 55
Simple ctrls : 27arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofsoundwire [sof-soundwire], device 1: Headset mic (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 3: DMIC (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 4: DMIC16kHz (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0but
arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
samplerate
Rate Converter Plugin Using Samplerate Library
speexrate
Rate Converter Plugin Using Speex Resampler
jack
JACK Audio Connection Kit
oss
Open Sound System
pulse
PulseAudio Sound Server
upmix
Plugin for channel upmix (4,6,8)
vdownmix
Plugin for channel downmix (stereo) with a simple spacialization
usbstream:CARD=sofsoundwire
sof-soundwire
USB Stream Output@aigilea can you re-run alsa-info now and upload the results on the alsa-project site? It'll be useful for the next step of UCM changes. Thanks!
Describe the bug Both legacy driver and SOF driver only create devices for HDMI outputs, no speakers or headphones (or microphones). I've tried 5.8, 5.10 and 5.11 kernels with the latest 1.6.1 SOF distribution, the only difference is wording changed from dmic-related to soundwire-related around SOF initialization in dmesg. PulseAudio refuses to init the card when SOF driver is enabled, playing sounds to /dev/snd/pcm* devices doesn't result in any output to speakers or headphones. Laptop has the latest firmware (F.10 Rev.A) and there's no problem with sound in Windows obviously. I'm running ubuntu, but according to the forum thread it's the same on Arch with the 13-aw2777ng laptop (it's basically the same hardware).
There's a wiki page on a similar 14-inch laptop describing some gpio trickery to enable the amplifier, but it assumes a functional pulseaudio with created sinks and so on. I've done that anyway to no avail -- pulseaudio still refuses to init and no sound is produced when playing to pcm devices.
lspci -vexcerptdmesg|egrep -i "(dsp|sof|snd)"There's ABI mismatch currently but I don't know where to get ABI3:18 SOF and the problem was the same with matching ABIs for both fw and topology.
ls -la /dev/snd/aplay -luname -apulseaudio -v(pulseaudio daemon is stopped. I've tried to delete pulseaudio config with the same result)sof-logger -l ../../lib/firmware/intel/sof/v1.6.1/sof-tgl-v1.6.1.ldc(I guess this is expected)fuser -v /dev/snd/*gives empty result.pactl list cardsgives empty result as well when pulseaudio is running.Can you please fix that or point me in the right direction if you think problem is elsewhere?
Update 19.01.2021 There were some UCM-related improvements in pulseaudio 14.x, so I've built it from the git to no avail.
pulseaudio -v(config files are removed)I've also tried it with the latest userspace alsa lib, tools, fw and UCM, the only difference is the missing pcm name in the log