Created attachment 1759676 [details] related logs 1. Please describe the problem: I have ALC256m soundcard and intel microphone array in a Xiaomi Redmi notebook. Soundcard is not recognized so there is just a "dummy output" which cannot produce any sound of course, dmesg shows that module snd-hda-intel detects dsp and dmic, it loads the sst driver snd-soc-skl (alsa-sof-firmware installed). If I balcklist snd-soc-skl and force snd-hda-intel not to detect dmic, the legacy driver works without dmic but 3.5mm only produces mono channel sound, and the microphone from headset dose not work (tested on latest ubuntu, I just moved to f33 and that should be the same). 2. What is the Version-Release number of the kernel: stock 5.10.17-200.fc33.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Not verified but it should work partially (without microphone and wrong 3.5mm jack lines) before you imported dmic and sst driver. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Power on and listen. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Sorry but again not verified, I don't have the bios password. If you can sign it I 'm willing to give it a go. 6. Are you running any modules that not shipped with directly Fedora's kernel?: nope. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Created attachment 1761167 [details] alsa-info output
seems that fedora has disabled CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC in its kernel config, which makes the realtek codec unavailable when using sst driver.I don't have the bios passcode to test a custom kernel, but maybe this kconfig should be enabled for sound cards using SST drvier to be functional.
Folowwing https://gist.github.com/crojewsk/4e6382bfb0dbfaaf60513174211f29cb sound output and dmic start to work, but still needs further fixing. The volume for microhpne is too low to record any sound, 3.5mm detection fails, and the combo jack is not working. But first, kernel configuration CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC in fedora should be toggled on.
The issue has been filed to bugzilla.kernel, see : https://bugzilla.kernel.org/show_bug.cgi?id=212081 With proper kconfig and kernel source from fedora source tree,skylake devices with modern dmic start to work, but further fixes about microphone volume, suspend/resume, and jack pin are needed.
Re-assigning this to alsa-lib so that the right people can take a look at it.
(In reply to Hans de Goede from comment #5) > Re-assigning this to alsa-lib so that the right people can take a look at it. According to the maintainer from intel on kernel.bugzilla, the skylake driver takes a kernel config option and some alsa topology files to function, which can be done easily but yet easier if fedora optimize its kconfig by default, which I think should be changed. The rest about suspend/resume and specific model related issues are about alsa-lib I think, thanks for concerning.
Created attachment 1762235 [details] alsa-info from a working kernel built form fedora 33 tree, only with one additional kconfig=y
Confirming this works on another Xiaomi Device (vendor id [1d72:1947]) with kbl soundcard and dmic, it should solve "no sound/dummy output" problems on all machines with kbl/skl soundcards and dmic, after kernel version 5.8(snd skl support patch included but codec kconfig not set). To make it fully functional, we needs some quirks to deal with suspend/volume/jack pins, but I'm on a cml-y processor, it takes too long to compile over and over again. Can someone with similar hardwares (dmic and realtek soundcard, especially 8086:9d71/9d70 on thinkpad c930/ASUS Swift/Xiaomi Redmibook/Huawei etc. machines) experiencing the same sound or microphone issues help to try this out? And since this can be addressed by adding a kconfig option, the best way would be that fedora build the kernel for testing with correct configuration, thus only the module needs to be re-compiled for fixing purpose.
Those things seem all kernel related (HDA codec driver issue and the SST MIC issue), except the topology file. I will include the binary topology file to the alsa-sof-firmware probably (altough it's for the older driver which is not SOF related).
(In reply to Jaroslav Kysela from comment #9) > Those things seem all kernel related (HDA codec driver issue and the SST MIC > issue), except the topology file. Right, my reason to change the component to alsa-lib was to get you to look at this. Specifically I'm not familiar with the Kconfig options related to sound on Skylake and sometimes enabling one option may cause another driver to be disabled. I've just checked and it seems that the CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option is not mutually-exclusive with any other options, so it should be safe to enable it. Jaroslav, do you agree that it should be safe to enable the CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option ?
(In reply to Jaroslav Kysela from comment #9) > Those things seem all kernel related (HDA codec driver issue and the SST MIC > issue), except the topology file. > > I will include the binary topology file to the alsa-sof-firmware probably > (altough it's for the older driver which is not SOF related). It's build againt this repo https://github.com/alsa-project/alsa-topology-conf(if it's any help), not related to my particular situation(hda_dsp) only but a few other architectures. And yes there is no existing packages in fedora related to these binaries. Without those such old drivers on new machines with dsp and dmic won't, so your decision to package them is definitely important.
(In reply to Hans de Goede from comment #10) > I've just checked and it seems that the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option is not mutually-exclusive > with any other options, so it should be safe to enable it. > > Jaroslav, do you agree that it should be safe to enable the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option ? I agree. It should be safe.
(In reply to Hans de Goede from comment #10) > (In reply to Jaroslav Kysela from comment #9) > > Those things seem all kernel related (HDA codec driver issue and the SST MIC > > issue), except the topology file. > > Right, my reason to change the component to alsa-lib was to get you to look > at this. > > Specifically I'm not familiar with the Kconfig options related to sound on > Skylake and sometimes enabling one option may cause another driver to be > disabled. > > I've just checked and it seems that the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option is not mutually-exclusive > with any other options, so it should be safe to enable it. > > Jaroslav, do you agree that it should be safe to enable the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option ? I've tried to modify this particular option from the official fedora source tree, rebuild the kernel and it works with no obvious downsides(well, for my test at least), it has to be set to"=y" otherwise (=m) the kernel won't compile. cezary.rojewski commented in my bug on bugzilla.kernel(https://bugzilla.kernel.org/show_bug.cgi?id=212081) and his own gist(https://gist.github.com/crojewsk/4e6382bfb0dbfaaf60513174211f29cb) that it's how sky/kbl devices work with the SST driver. Intel has closed another issue on github to add SOF supoort for these platforms and commented "this is not gonna happen", so it seems that's the only way to solve this.
I've submitted merge-requests to turn the CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option on for the Fedora rawhide and 5.11 kernels: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/965 https://gitlab.com/cki-project/kernel-ark/-/merge_requests/966
(In reply to Hans de Goede from comment #14) > I've submitted merge-requests to turn the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option on for the Fedora rawhide > and 5.11 kernels: > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/965 > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/966 That's efficiency. And I've found that the NIDs can be corrected by adding model=alc255-xiaomi-headset when using legacy driver. It does the following: [ALC255_FIXUP_XIAOMI_HEADSET_MIC] = { .type = HDA_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 }, { } }, .chained = true, .chain_id = ALC289_FIXUP_ASUS_GA502 } The chain patch calls for a hda_pintbl: 0x19, 0x03a11020 , together jack detection and all jacked stuffs work perfectly. This patch already exist for another older Xiaomi device with alc255 (see: https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c#L7797-L7806), applied to a previous model as an snd-hda-intel option. So the legacy driver issue can be easily fixed by one additional line like: "SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSET_MIC),", which can be added under other Xiaomi contents. HOWEVER I have no idea how to make this happen with the SST driver. Do you know how to write a quirk which dose the same in the SST driver?
(In reply to Hans de Goede from comment #14) > I've submitted merge-requests to turn the > CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC option on for the Fedora rawhide > and 5.11 kernels: > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/965 > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/966 Cezary.rojewski told me that asoc codecs are just wrappers on ordinary hda codecs, so the patch above shall impact both the pins of this machine under hda and sst,(https://bugzilla.kernel.org/show_bug.cgi?id=212081#c13) and yes it does. So I think a proper kconfig, tplg files pre-packaged, and the simple patch "SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSET_MIC)," in "patch_realtek.c" get audio fully functional out of the box. As for the low volume of microphone, changing offsets in the ucm file helps, but not suitable for all machines. So simply over-amplifying the mic in pulse control solves it.
Thanks to the work of many, this is nearly done (for fedora at least). The problem happens on a variety of machines with dmic connected to SOCs on skl/kbl platform, no distro has got the correct kconfig and tplg files by default. It's been verified that fedora kernels built with above fixes work on two different models of Xiaomi laptops, it should work on other machines as well. (like Lenovo/Asus etc. mentioned above) TLP caused one of them lost sound after suspend/resume, but that has nothing to do with the kernel or fedora. TLP suspend\resume hooks stops the soc from waking up after s0ix (S3 works fine). Without TLP everything seems OK, since TLP isn't installed by default, this should be fine. The last to do is fixing the jack pins, which can be done by inserting patches to "sound/pci/hda/patch_realtek.c", I have figured out : "SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSET_MIC)," works on model Xiaomi TM1947, and "SND_PCI_QUIRK(0x1d72, 0x1701, "XiaomiNotebook Pro", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE)," works on model TM1701, or the existing patches can be re-written with model names to reduce confusion. Shall this be added here in fedora for testing first, or be submitted to the up stream kernel directly?
(In reply to 尉晓亮 from comment #17) > Shall this be added here in fedora for testing first, or be submitted to the up stream kernel directly? Please, send your changes to upstream (with Cc: to stable) so we can pick the changes quickly to the Fedora kernels. Could you test https://kojipkgs.fedoraproject.org//work/tasks/7273/63617273/alsa-sof-firmware-1.6.1-4.fc35.noarch.rpm package? It should contain the pre-compiled /usr/lib/firmware/skl_hda_dsp_generic-tplg.bin topology file. It can be installed on any Fedora version. Thank you.
(In reply to Jaroslav Kysela from comment #18) > (In reply to 尉晓亮 from comment #17) > > > Shall this be added here in fedora for testing first, or be submitted to the up stream kernel directly? > > Please, send your changes to upstream (with Cc: to stable) so we can pick > the changes quickly to the Fedora kernels. > > Could you test > https://kojipkgs.fedoraproject.org//work/tasks/7273/63617273/alsa-sof- > firmware-1.6.1-4.fc35.noarch.rpm package? It should contain the pre-compiled > /usr/lib/firmware/skl_hda_dsp_generic-tplg.bin topology file. It can be > installed on any Fedora version. Thank you. Yes, it works, and the file you added is absolutely the same as I compiled. Thank you.
(In reply to Jaroslav Kysela from comment #18) > (In reply to 尉晓亮 from comment #17) > > > Shall this be added here in fedora for testing first, or be submitted to the up stream kernel directly? > > Please, send your changes to upstream (with Cc: to stable) so we can pick > the changes quickly to the Fedora kernels. > > Could you test > https://kojipkgs.fedoraproject.org//work/tasks/7273/63617273/alsa-sof- > firmware-1.6.1-4.fc35.noarch.rpm package? It should contain the pre-compiled > /usr/lib/firmware/skl_hda_dsp_generic-tplg.bin topology file. It can be > installed on any Fedora version. Thank you. Err...Sorry to disturb you Sir, I have send the patch but because of some network problem in China, currently I cannot use my gmail account via VPN, so I send the mails using OUTLOOK.com, which has been rejected by stable.org. The mail has been also send to you according to the sub-maintainers list, could you please help me with that? (Really sorry about that, you know about the network blocking here....) There are two patches, one concerning model TM1947, and the other for TM1701.