thesofproject
[BUG] Huawei MateBook E DRR-W76 - the speakers are not working
alsa-info: http://alsa-project.org/db/?f=4c40d6b4f04981eab230e4425cef7aabfeffac44
After applying patch from https://github.com/thesofproject/linux/issues/5038, the speakers really started working, but only on the right side. Moreover, the left and right sounds worked separately, but the left one sounded noticeably quieter, so I decided to test it on Windows. In Windows, the left sound is on the left of the MateBook, and the right one is on the right.
After reinstalling Linux, the speakers stopped working even with the patch, but the microphone remained working.
Legacy mode (options snd-intel-dspcfg dsp_driver=1) does not help at all, the speakers and the microphone do not work.
Apparently, the firmware has been updated ;(
What can I do to solve this problem? I have already written to HUAWEI tech support about the problem with a link to this issue.
I am afraid there's no simple answer: https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#reverse-engineer-the-windows-audio-driver
I played around a bit with the PIN config of 0x1d via hdajackretask, but nothing worked. There is also a problem that the drivers for HUAWEI are downloaded through the application, and not through the website.
For history:
- Codec: Conexant CX11970
- https://lore.kernel.org/all/[email protected]/
I'm stuck.
I try to follow the instructions from https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver, but here was a problem from here:https://github.com/ryanprescott/realtek-verb-tools/issues/2 https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Gotchas_3:
IOMMU groups
IOMMU group 7
00:0d.0 USB controller [0c03]: Intel Corporation Alder Lake-P Thunderbolt 4 USB Controller [8086:461e] (rev 06)
00:0d.2 USB controller [0c03]: Intel Corporation Alder Lake-P Thunderbolt 4 NHI #0 [8086:463e] (rev 06)
IOMMU group 15
00:1f.0 ISA bridge [0601]: Intel Corporation Alder Lake LPC Controller [8086:5187] (rev 01)
00:1f.3 Multimedia audio controller [0401]: Intel Corporation Alder Lake Smart Sound Technology Audio Controller [8086:51cc] (rev 01)
00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake PCH-P SMBus Host Controller [8086:51a3] (rev 01)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-P PCH SPI Controller [8086:51a4] (rev 01)
IOMMU group 5
[RESET] 00:07.0 PCI bridge [0604]: Intel Corporation Alder Lake-P Thunderbolt 4 PCI Express Root Port #0 [8086:466e] (rev 06)
IOMMU group 13
00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01)
IOMMU group 3
00:04.0 Signal processing controller [1180]: Intel Corporation Alder Lake Innovation Platform Framework Processor Participant [8086:461d] (rev 06)
IOMMU group 11
[RESET] 00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
IOMMU group 1
[RESET] 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP4 GT2 [Iris Xe Graphics] [8086:46aa] (rev 0c)
IOMMU group 8
00:10.0 Serial bus controller [0c80]: Intel Corporation Alder Lake-P Serial IO I2C Controller #2 [8086:51d8] (rev 01)
00:10.1 Serial bus controller [0c80]: Intel Corporation Alder Lake-P Serial IO I2C Controller #3 [8086:51d9] (rev 01)
IOMMU group 16
[RESET] 01:00.0 Non-Volatile memory controller [0108]: Phison Electronics Corporation PS5021-E21 PCIe4 NVMe Controller (DRAM-less) [1987:5021]
IOMMU group 6
[RESET] 00:08.0 System peripheral [0880]: Intel Corporation 12th Gen Core Processor Gaussian & Neural Accelerator [8086:464f] (rev 06)
IOMMU group 14
00:19.0 Serial bus controller [0c80]: Intel Corporation Alder Lake-P Serial IO I2C Controller #0 [8086:51c5] (rev 01)
00:19.1 Serial bus controller [0c80]: Intel Corporation Alder Lake-P Serial IO I2C Controller #1 [8086:51c6] (rev 01)
IOMMU group 4
[RESET] 00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 [8086:464d] (rev 06)
IOMMU group 12
00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01)
00:15.1 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 [8086:51e9] (rev 01)
IOMMU group 2
00:00.0 Host bridge [0600]: Intel Corporation Alder Lake Host and DRAM Controller [8086:4602] (rev 06)
IOMMU group 10
00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01)
00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01)
IOMMU group 0
[RESET] 00:05.0 Multimedia controller [0480]: Intel Corporation Alder Lake Imaging Signal Processor [8086:465d] (rev 06)
IOMMU group 9
00:12.0 Serial controller [0700]: Intel Corporation Alder Lake-P Integrated Sensor Hub [8086:51fc] (rev 01)
00:12.6 Serial bus controller [0c80]: Intel Corporation Device [8086:51fb] (rev 01)
According to https://bugzilla.kernel.org/show_bug.cgi?id=207423#c19, Windows drivers should solve it. But Windows does not want to install drivers for 8086:51сс in any way. It turned out that Huawei has drivers for sound on the site, but after installing the miracle did not happen - Windows does not see the speakers. Even considering that everything is OK in the Device Manager.
I have one last idea: install both Windows and Linux on the system, download all the drivers on Windows (https://www.tenforums.com/backup-restore/141466-how-backup-import-device-drivers-windows-10-using-powershell.html) and transfer them to the Linux virtual machine.
And while I was following the instructions, the sound card stopped displaying again: http://alsa-project.org/db/?f=d7437f5d8e5fda1a2ef00d2713f0598d0dc5ffda I am sure that the problem will be fixed by the usual reinstallation of Linux, but please tell me how to solve it in a less radical way.
I succeeded in install the drivers from the real system to the virtual machine and finally the verbs appeared. Windows sees the speakers, shows that there is sound, but in fact there is not. I mean, I can't hear him. Just like on Linux.
Unlike a real system, there is no Intel Smart Sound Technology MIPI soundwire controller in the virtual machine.
I do not know how to pass it to a virtual machine, since the hardware ID show INTELAUDIO\SDW_ROOT.
sniff-verbs-huawei-drr-w76.txt
It may be enough to turn on additional power via GPIO to make the speakers work. But I do not know how: gpioinfo0.txt gpioset0-23-1.txt
if you have an HDaudio codec, there is no relationship or dependency on SoundWire. Different bus/interface/pins.
$ cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 512-871, parent: platform/INTC1055:00, INTC1055:00:
gpio-535 ( |power-enable ) out lo
gpio-583 ( |privacy-led ) out lo
gpio-655 ( |power-enable ) out lo
gpio-869 ( |privacy-led ) out lo
@andy-shev, since you are a Linux maintainer Intel Alder Lake PCH pinctrl/GPIO driver ./drivers/pinctrl/intel/pinctrl-alderlake.c, can I count on your help after returning from vacation in mid-August??
$ cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-871, parent: platform/INTC1055:00, INTC1055:00: gpio-535 ( |power-enable ) out lo gpio-583 ( |privacy-led ) out lo gpio-655 ( |power-enable ) out lo gpio-869 ( |privacy-led ) out lo
These are unrelated. According to names they are seem for cameras.
@andy-shev, since you are a Linux maintainer
Intel Alder Lake PCH pinctrl/GPIO driver./drivers/pinctrl/intel/pinctrl-alderlake.c, can I count on your help after returning from vacation in mid-August??
Not sure how. I think the GPIOs you are talking about are on the codec chip and have no common ground with the Intel SoC ones. You need to have a schematic of the piece of the hardware in question.
If I don't have one, is there anything else I can do? What do I need to reverse to figure out how to turn on the speakers?
Without knowledge of the hardware layout, it's next to impossible to guess...
Will I be able to get the necessary information by disassembling this laptop? Of course, I take full responsibility.
Will I be able to get the necessary information by disassembling this laptop?
Without special hardware to scan PCBs, usually some kind of introscope similar to what is used at airport security checkpoints, modern layout cannot be reversed. Much easier to find a board view (premodeled “scans”), or schematic. So, don’t break your laptop, it won’t help much.
@rautyrauty, did this issue got resolved over time with kernel updates? Are you sure that the laptop have cx11970 (https://github.com/thesofproject/linux/issues/5051#issuecomment-2196660580)? I'm asking because in other links the referred codec is ALC298...
Without direct support from the OEM (Huawei) it is not that easy (iow, shot in the dark) to figure out what verbs needs to be set and how things are connected.
Given that legacy HDA stack behaves the same way, this is out of our reach.
@rautyrauty, did this issue got resolved over time with kernel updates?
I don't know, I don't have this laptop right now. It is not mine. I'll try to get it out again on Monday.
Are you sure that the laptop have cx11970 (#5051 (comment))?
I wrote this based only on information from alsa-info (see https://github.com/thesofproject/linux/issues/5051#issue-2344043875).
I'm asking because in other links the referred codec is ALC298...
Please share these links.
Without direct support from the OEM (Huawei) it is not that easy (iow, shot in the dark) to figure out what verbs needs to be set and how things are connected. Given that legacy HDA stack behaves the same way, this is out of our reach.
Yes, you're right. I tried to write directly to HUAWEI technical support, but they didn't help me and, of course, refused to provide schematics.
@rautyrauty, OK, I see. The machine have single HDA codec and no display audio capability:
[ 4.141512] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 1
There are 4 DMICs (thus SOF is used)
[ 4.141518] sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 4
The single HDA codec is CX11970:
[ 4.257770] snd_hda_codec_conexant ehdaudio0D0: CX11970: BIOS auto-probing.
[ 4.258765] snd_hda_codec_conexant ehdaudio0D0: autoconfig for CX11970: line_outs=2 (0x1d/0x26/0x0/0x0/0x0) type:speaker
[ 4.258767] snd_hda_codec_conexant ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 4.258768] snd_hda_codec_conexant ehdaudio0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0)
[ 4.258769] snd_hda_codec_conexant ehdaudio0D0: mono: mono_out=0x0
[ 4.258769] snd_hda_codec_conexant ehdaudio0D0: inputs:
[ 4.258770] snd_hda_codec_conexant ehdaudio0D0: Mic=0x19
[ 4.268138] input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17
[ 4.268177] input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input18
[ 4.268754] leds platform::micmute: Setting an LED's brightness failed (-19)
The mic mute LED brightness error is a curious one, but should not affect functionality, afaik.
The flood of
sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_dai_hw_params on iDisp1/2/3 Pin: -22
is caused by PA/PW probing the PCMs and the display audio is not functional as there is no idisp codec in the system. This should not affect analog audio use.
The lack of display audio is interesting, the device does not have support for external HDMI/DP monitors with audio?
Looking around the net and it looks like that it is not uncommon to have non working audio on this vendor's systems, regardless if they use Intel or AMD. I don't think you need schematics, but a patch from Huawei/Senarytech to provide the needed quirk/configuration for the codec in this machine, the BIOS provided info likely incorrect?
I guess, it is up to trial and error to figure it out, other machines from the same vendor w/ CX11970 have different pin config and they seams to have issues of their own as well. https://bbs.deepin.org/en/post/280104 https://bbs.archlinux.org/viewtopic.php?id=300732
I'm really sorry, but I don't think we can help with this further :(
I'm really sorry, but I don't think we can help with this further :(
@ujfalusi, thank you for taking the time to write my issue. We did everything we could, and that's the most important thing!
I have no objections if you close this issue.
@rautyrauty, thank you. Do let us (and the world) know if you manage to get this working. Probably if more people nag OEMs they might consider stepping up, it should not be a big task to fix these issues with the knowledge of how things are connected.