00:09 <farkuhar> ukky: Thanks for the hints. The return value in the dmesg output has always been -2, which probably didn't come from pcim_enable_device(pci) or pci_request_regions(pci,"Audio DSP") because of the accompanying debug message. But if EINVAL is not 2, then I was on the wrong track to suspect problems with the sof ipc_type.

00:16 <farkuhar> Instead I should probably follow your suggestion of playing with the filenames. I suspect the sof_pci_probe() function got all the way to populating sof_pdata and then got its return value from snd_sof_device_probe. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/soc/sof/sof-pci-dev.c?h=v6.6.31#n341

00:22 <ukky> Error 'codec #2 probe error, ret: -2' comes from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/soc/sof/intel/hda-codec.c?h=v6.6.31#n178

00:40 <farkuhar> Tracing it further back, the return value itself comes from ((resp & 0xFFFF0000) == IDISP_VID_INTEL) && (!hbus->core.audio_component)) , which would seem to relate to the earlier dmesg "init of i915 and HDMI codec failed". Is there a module option I can pass so that it only probes the internal sound card, rather than also trying to initialize the HDMI port?

00:54 <farkuhar> That earlier dmesg comes from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/hda/hdac_i915.c?h=v6.6.31#n174 , so maybe there was an oversight in make menuconfig that allowed me to build i915 directly into the kernel, rather than requiring it to be a module as soon as I selected snd_hda_intel as a module.

00:55 <ukky> This option might disable HDMI audio: https://lore.kernel.org/all/20200415162523.27499-1-tiwai@suse.de/

00:56 <ukky> No need to recompile kernel to test <module>.enable_acomp

01:00 <remiliascarlet> ppetrov^: "or as the youngsters like to say "apps"" There is a reason why I never refer a program to an "app". Because Steve Jobs successfully brainwashed the world into using "app" instead of "program", "application", "driver", "game", "OS", "firmware", or whatever other type of software, so that everyone makes the subcontious association to "Apple" whenever they say "app".

01:00 <farkuhar> ukky: so that would be "options snd_hda_codec_hdmi enable_acomp=0" somewhere under /etc/modprobe.d/? Or does enable_acomp go with a different module?

01:03 <ukky> Never used this option, here is one use case: https://bbs.archlinux.org/viewtopic.php?pid=2009982#p2009982 (just remove 'enable_silent_stream = off')

01:04 <ukky> Or you can try adding to kernel command line: snd_hda_codec_hdmi.enable_acomp=0

01:07 <farkuhar> ukky: I'll give it a try, but only after a good night's sleep. That particular device has been powered off for now. Thanks for your help tonight!

01:09 <ukky> You are welcome

01:10 <remiliascarlet> My mom got tricked into using the A-word, and often confuses "Apple" with "smartphone application". Like how she's referring LINE (a popular chat program in Japan and Korea) to as "a chat apple".

01:13 <remiliascarlet> Or things like "why won't you buy an app" instead of "why won't you buy an iPhone".

03:05 <remiliascarlet> SiFuh: When an American defines different cuts of beef: https://www.thespruceeats.com/thmb/8NmhjqlSRczVL9VsVtlPyoyqTLw=/1500x0/filters:no_upscale():max_bytes(150000):strip_icc()/SPR_995304-cuts-of-beef-chuck-loin-rib-brisket-and-more_Rib-5a8b2f9f04d1cf0036a5a101.png | When a Japanese defines different cuts of beef: https://tv-gourmet.net/wp-content/uploads/s00005_03.jpg

10:46 <farkuhar> ukky: Successful detection of the soundcard just now. It seems to be another side effect of the failure to auto-load a required module (just like iwlmvm wasn't being loaded automatically with iwlwifi). In this case, the module that failed to auto-load was snd_hda_codec_hdmi. Once I modprobed it manually, ALSA could see the card just fine.

10:48 <farkuhar> Maybe I should follow SiFuh's example and control all the module loading by hand, if this hardware is not giving the kernel enough information about the modules it needs.

13:49 <ukky> farkuhar: kernel module loading is still a mistery to me. Great that you found a way to fix audio issue on that system.

13:54 <ukky> farkuhar: can you try adding this line after /sys and /proc are mounter, but before udev is started: for _m in $(/sbin/kmod static-nodes -f devname 2>/dev/null | cut -d' ' -f1); do echo "Loading module $_m"; /sbin/modprobe -bq "$_m"; done

13:57 <ukky> farkuhar: The above is just to test if pre-loading static nodes fixes autodetection later when udev is being loaded

16:08 <farkuhar> ukky: will try it, thanks for the idea. It's also the first device on which I replaced the proprietary firmware with Coreboot, so maybe that has something to do with the module loading issues.

16:14 <ukky> farkuhar: Coreboot might be another source of audio issues, as Linux kernel depends on the device tree that Coreboot reports to the kernel. Meaning, you need a Coreboot that was compiled for your specific HW.

18:05 <farkuhar> ukky: on the latest reboot, the kmod static-nodes loop did not echo anything. But after logging in, `kmod static-nodes` _does_ show a few modules, so somehow those static nodes were detected between launching udev and acquiring a login shell.

18:06 <farkuhar> anyway, thanks for pointing out the enable_acomp parameter of the snd_hda_codec_hdmi module. That option was the key to getting audio working at last.

18:15 <ukky> farkuhar: in theory, that HDMI audio device should not affect the discovery of your second audio device. But I assume you will not be using HDMI audio (unless you hook HDMI TV)

18:46 <farkuhar> ukky: correct, I don't have any plans to use HDMI audio on this device. The internal speakers and the 3.5mm jack should cover all the intended use-cases.