[BUG] No sound on HP Spectre x360 13-aw2022ur (2020, Tiger Lake) #2700
Comments
|
I can confirm this, same issue here on my HP Spectre x360 13-aw2777ng |
|
@bardliao @libinyang this seems to be soundwire device... any idea why we don't have pcm devices? |
The 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. And, please show me the result of Thanks |
|
Attaching full dmesg with dyndbg.
|
|
Here's my output of and my dmesg. |
From above, the codecs on your device is rt711 and rt1308. So, we have to add the codec information to BIOS at first. We need to figure out who can help on it. @mengdonglin
It is a TGL device and the match table is snd_soc_acpi_intel_tgl_sdw_machines[]. 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. |
|
There's some progress. I'm attaching the new dmesg and just in case dsdt. upd. |
|
@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. |
|
@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. |
|
@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. |
On some HP devices, the BIOS does not advertise the presence of RT711 on link0 and RT1308 on link1. This has been a known issue on reference platforms, but this problem was not expected to spill into commercial devices. Unfortunately the BIOS remained broken and we can't reasonably expect every Linux user to override the DSDT. This patch suggests the use of a workaround. Broken BIOS expose the part 0x701 on all links, which does not correspond to a real device or configurations. We can however use this information to make existing codec drivers can probe on this device instead. BugLink: thesofproject#2700 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
@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 #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. |
On some HP devices, the BIOS does not advertise the presence of RT711 on link0 and RT1308 on link1. This has been a known issue on reference platforms, but this problem was not expected to spill into commercial devices. Unfortunately the BIOS remained broken and we can't reasonably expect every Linux user to override the DSDT. This patch suggests the use of a workaround. Broken BIOS expose the part 0x701 on all links, which does not correspond to a real device or configurations. We can however use this information to make existing codec drivers probe on this device instead. BugLink: thesofproject#2700 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
You can enable dynamic debug by copying this file |
|
@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. |
On some HP devices, the BIOS does not advertise the presence of RT711 on link0 and RT1308 on link1. This has been a known issue on reference platforms, but this problem was not expected to spill into commercial devices. Unfortunately the BIOS remained broken and we can't reasonably expect every Linux user to override the DSDT. This patch suggests the use of a workaround. Broken BIOS expose the part 0x701 on all links, which does not correspond to a real device or configurations. We can however use this information to make existing codec drivers probe on this device instead. BugLink: thesofproject#2700 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
On some HP devices, the BIOS does not advertise the presence of RT711 on link0 and RT1308 on link1. This has been a known issue on reference platforms, but this problem was not expected to spill into commercial devices. Unfortunately the BIOS remained broken and we can't reasonably expect every Linux user to override the DSDT. This patch suggests the use of a workaround. Broken BIOS expose the part 0x701 on all links, which does not correspond to a real device or configurations. We can however use this information to make existing codec drivers probe on this device instead. BugLink: thesofproject#2700 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
@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. |
|
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! |
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. |
|
@aigilea Could you add |
|
|
@kv2019i @libinyang please check this on ADL and report a bug to BIOS team. It is too late to report it after PV. |
On some HP devices, the BIOS does not advertise the presence of RT711 on link0 and RT1308 on link1. This has been a known issue on reference platforms, but this problem was not expected to spill into commercial devices. Unfortunately the BIOS remained broken and we can't reasonably expect every Linux user to override the DSDT. This patch suggests the use of a workaround. Broken BIOS expose the part 0x701 on all links, which does not correspond to a real device or configurations. We can however use this information to make existing codec drivers probe on this device instead. BugLink: thesofproject#2700 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
@marian556 |
|
Yes , it works. Thanks agilea. You saved me. this version of alsa-ucm-conf just works. Latest does not. |
|
@aigilea . Is it a good idea to introduce changes into alsa-ucm-conf that are not backward compatible with older alsa-utils. It was not possible to maintain alsa-ucm-conf compatibility with alsa-utils 1.2.4 for some time. Could a new syntax could be introduced alongside the old one? How are you going to communicate incompatible changes to all distributions, such as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921632 ? @plbossart . Proposed ubuntu kernel 5.11 release candidate in testing by ubuntu with this sof-soundwire patches still does not work for me. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921632 compare comments #46 and #40 |
|
@marian556 I have no idea what Ubuntu are doing and can't do their work. You have Hui Wang's contact, please work with him. |
|
@marian556 I've used 5.11 kernel with the following patches, they are certainly heavily outdated now, but it worked |
|
Incredible ... speakers, HDMI output and microphone input are working or at least I can hear speakers and see the others in the list of available options. I will test it thoroughly later and report if I find any issue. The final touch needed was the UCM version from @aigilea like in @marian556 's case. Thank you very much guys. The notebook arrived two days ago and I didn't expect speakers working anytime soon. This kind of support totally exceeded my expectations. Btw: Above doesn't work with sof-firmware 1.8-rc2. Is it something worth reporting or is it just a bad mixture of versions in my system? |
|
Glad you have a solution @by-cx. We've worked hard to make things work out of the box, too bad you tested too early :-) Please do report the issue with firmware 1.8-rc2 separately, that's precisely the intent of -rc candidates. We don't have a lot of devices and we rely on the community early adopters to let us know of issues. |
|
@plbossart I started testing it in the right time :-) Thank you again, I will report the issue with 1.8-rc2 👍 |
HP Spectre x360 Convertible devices expose invalid _ADR fields in the DSDT, which prevents codec drivers from probing. A possible solution is to override the DSDT, but that's just too painful for users. This patch suggests a simple DMI-based quirk to remap the existing invalid ADR information into valid ones. BugLink: thesofproject#2700 Co-developed-by: Bard Liao <yung-chuan.liao@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> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210302075105.11515-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
I know this bug is closed, and after I just installed the Ubuntu kernel for 5.13 ... things look very good. dmesg https://pastebin.com/MyfJhckp But despite alsa now loading the correct kernel module ... no sound. I have checked alsamixer and the speakers were 'off' - but I toggled them On.. Certainly the Sound control panel items sees and plays with the card - but no sound. So I am really not sure that the 'quirk : -1' did its job properly ... or maybe someone else has an idea ?? |
|
@ronohara You need this kernel, SOF firmware 1.7 and the right combination of UCM and SOF topology. You are on alsa-lib 1.2.2 and everything started working for me out of the box when new SOF firmware and upgrade of alsa-lib to 1.2.5 arrived to my system. I don't think there is alsa-lib 1.2.5 in Ubuntu yet so you can do what I did at the beginning. Here is new version of SOF firmware and topology: https://github.com/thesofproject/sof-bin And in this comment there is a link to the right version of UCM, that worked for me: All you need is to copy those into the right locations of your system. SOF will install into /lib/firmware/intel/ with the included script. UCM, at least in my Fedora, is located here: /usr/share/alsa. |
|
@by-cx I compiled and installed alsa-lib-1.2.5.1 and alsa-tools-2.1.5.1 from source - Ubuntu packages do not seem to be flowing yet. And I installed the new SOF firmware and topology directly from guthib ... but no joy. Alsa is still working if I attach bluetooth speakers. On reboot it sees the soundwire care ... but 'test speakers' = silence. dmesg.txt https://pastebin.com/7PsJ9ihp any thoughts ? |
|
@ronohara if you installed the latest firmware 1.8, you also need the latest alsa-ucm-conf. |
|
@plbossart I had installed the latest alsa-ucm-conf cd /root BUT I got the link in /usr/share/alsa incorrect. Corrected it with: Rebooted - and there is a huge amount of activity from the kernel ... dmesg.txt https://pastebin.com/7ywNgKVK But still no sound. PS: Putting all this commentary in for posterity .. there is almost no documents or hints about setting up alsa-ucm-conf |
|
@ronohara you probably need to test the basics with command-line playback from a terminal alsaucm -c sof-soundwire set _verb HiFi set _enadev Speaker alsaucm -c sof-soundwire set _verb HiFi set _enadev Mic if you don't hear sound or don't see any activity on the record there is something wrong with your setup. |
|
@plbossart Interesting .... speaker-test works !!! plenty of 'pink noise' and left/right is distinct (I will worry about the Mic later) speaker-test 1.2.5.1 Playback device is hw:0,2 But the Sound Control 'test' button does not work ... and applications using alsa don't work either. |
|
@ronohara I guess it's a problem with the UCM2 setup then, or PulseAudio not getting the right config. |
|
@plobssart ... still no joy after upgrading alsa to 1.2.5 (lib, tools, utils) ... some traps for that. You need to remove the apt installed bits of alsa (1.2.2) before your compile /install from source, Otherwise some of the old version gets linked into the lib files. Upgraded to LM 20.2 as well. Status is: kernel 5.13 sees and uses the hardware just fine (dmesg.txt)... and alss-info shows all sorts of things as good. dmesg: https://pastebin.com/NXBrEMnJ The last line of alsa-info is weird: !!Packages installed rc alsa-utils 1.2.2-1ubuntu2.1 amd64 Utilities for configuring and using ALSA and yet using apt .. I get this... x360 tmp # apt remove alsa-utils the Sound Control still does not deliver sound - but does see the sof-soundwire card and I have output hardware set to Stereo and Speakers When you put the test button on the sound control, the dmesg log shows the kernel nudges the card and the card says that it worked ok ..... which is also odd. As an example: |
|
@ronohara maybe try removing/reinstalling libasound2-data. We've seen cases where bad mixer settings keep being used, and removing them helps. |
|
Hmm - apt purge libasound2-data ,,,, looks a bit dangerous The following packages will be REMOVED |
|
And alsamixer now has a library problem. Looks like I might have to compile quite a bit from source to get the 1.2.5 alsa support working. 360 tmp # alsamixer |
|
Hey @ronohara, in case it helps, I was able to build .deb files for alsa 1.2.5.1 from the debian sources for the future "sid" release for the following:
(libasound is part of alsa-lib) You can download the debian source bundles for these here, e.g. here's the one for alsa-lib you can then build the deb files from these sources using: (you will also need to install build dependencies but you probably have these already) That way you can easily install the 1.2.5.1 debs or got back to an older version using apt or dpkg However, even after doing all of this and using a 5.13 kernel, I am not able to get sound when I cold boot my system (linux mint 20 based on ubuntu 20.04) Will follow up separately with logs & further questions |
|
The jack detection doesn't seem to work on these HP x360 convertible devices, I added PR #3195 after local tests on a device. That helps with the ALSA mixer controls. I did find one case where the headset was not detected but that's not super reliable anyways. remove-insert forced the detection alright. Changing the device with the Gnome settings remains broken, something's not working between PipeWire, Gnome Settings and possibly UCM. @perexg FYI. The rest seems to work fine on Fedora 34 with the 5.14.9 kernel. speaker, local mics, headphones, headset record audio with decent levels. |
…Convertible HP Spectre x360 Convertible devices expose invalid _ADR fields in the DSDT, which prevents codec drivers from probing. A possible solution is to override the DSDT, but that's just too painful for users. This patch suggests a simple DMI-based quirk to remap the existing invalid ADR information into valid ones. BugLink: thesofproject/linux#2700 Co-developed-by: Bard Liao <yung-chuan.liao@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> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210302075105.11515-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> (cherry picked from commit f6594cd) BUG=b:238403794 TEST=Test Audio use cases. Signed-off-by: sboyane <shankarx.boyane@intel.com> Change-Id: I7b5844d1664f0466d153235813739951f08312d1
…Convertible HP Spectre x360 Convertible devices expose invalid _ADR fields in the DSDT, which prevents codec drivers from probing. A possible solution is to override the DSDT, but that's just too painful for users. This patch suggests a simple DMI-based quirk to remap the existing invalid ADR information into valid ones. BugLink: thesofproject/linux#2700 Co-developed-by: Bard Liao <yung-chuan.liao@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> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210302075105.11515-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> (cherry picked from commit f6594cd https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master) BUG=b:238403794 TEST=Test Audio use cases. Signed-off-by: sboyane <shankarx.boyane@intel.com> Change-Id: I58f42eb7a16fb77ea5d7736a78b2807f550cd630
and others
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
The text was updated successfully, but these errors were encountered: