In kernel 5.10, the Catpt driver was introduced for Haswell and Broadwell platforms to replace the legacy SST driver: https://patchwork.kernel.org/project/alsa-devel/cover/20200923122508.3360-1-cezary.rojewski@intel.com/ In addition, the snd-intel-dspcfg driver was updated so kernel builds could include both the Catpt and SOF drivers, and either one could be selected at runtime: https://lore.kernel.org/alsa-devel/20201112223825.39765-12-pierre-louis.bossart@linux.intel.com/ However, SOF_CARD_NAME and SOF_DRIVER_NAME (see the link directly above) are being used whenever kernel was built with CONFIG_SND_SOC_SOF_BROADWELL -- even when the Catpt driver is the one selected at runtime. Note that this card name does not get prepended with "sof-" as described in the code comments; so the card is not matching any ALSA userspace UCM profile, and the user has no sound (without resorting to manual manipulation of ALSA controls like SPO). I assume the intent was for CARD_NAME and DRIVER_NAME to be used instead, if the Catpt driver is selected at runtime? Those names match the legacy SST driver from kernel 5.9 and below. This is happening on my Dell Latitude 7350, which uses broadwell-rt286 audio. I first noticed this in Fedora 33, but then I tested it in Arch Linux using the stock kernel (CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=n) and a rebuilt kernel (CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y, otherwise identical).
Created attachment 295507 [details] alsa-info.txt with kernel 5.10.16-arch1-1
Created attachment 295509 [details] alsa-info.txt with kernel 5.10.16-arch1-1-custom (CONFIG_SND_SOC_SOF_BROADWELL=m)
Hello David, 'catpt' i.e. snd_soc_catpt is the official Intel recommended solution for Haswell and Broadwell devices with DSP audio onboard. Card/driver names should be left as: broadwell-rt286/null respectively in case of catpt driver. For not recommended configuration SOF, these are different. Checked alsa-ucm-conf/ucm2/ repo, broadwell-rt286 card configuration is still there and no changes were applied to it lately. From the alsa-info (non-custom) I see that broadwell-rt286 card enumerated properly and all the catpt's kcontrols are available for the use. Could you clarify what's the issue you're experiencing with audio? With card's name matching available ucm, everything should be just fine.
No idea what happens here. The card name is supposed to be determined based on the parent: /* set card and driver name */ if (snd_soc_acpi_sof_parent(&pdev->dev)) { broadwell_rt286.name = SOF_CARD_NAME; broadwell_rt286.driver_name = SOF_DRIVER_NAME; } else { broadwell_rt286.name = CARD_NAME; broadwell_rt286.driver_name = DRIVER_NAME; } David, can you try to see what happens in that snd_soc_acpi_sof_parent() function (defined in include/sound/soc-acpi.h)? It should be a string compare, not sure what causes the wrong path to be selected in your case.
Cezary, both examples here use 'catpt'. With CONFIG_SND_SOC_SOF_BROADWELL=m, catpt uses the wrong card/driver name. Note: this option does not mean SOF is used -- only that the kernel was built with the SOF driver included. This option is set in the stock Fedora 33 kernel, for example. Pierre, I now see the problem: The second patchset was actually not applied until kernel 5.11. Before that, the card name is (incorrectly) determined based on the kernel config instead: #if IS_ENABLED(CONFIG_SND_SOC_SOF_BROADWELL) /* use space before codec name to simplify card ID, and simplify driver name */ #define CARD_NAME "bdw rt286" /* card name will be 'sof-bdw rt286' */ #define DRIVER_NAME "SOF" #else #define CARD_NAME "broadwell-rt286" #define DRIVER_NAME NULL /* card name will be used for driver name */ #endif Kernel 5.10 has long-term support (at least 2 years). Can the following two commits be backported to it? I tested that this resolves the issue. 644eebdbbf11 ASoC: soc-acpi: add helper to identify parent driver. 8643e85aab87 ASoC: Intel: broadwell: set card and driver name dynamically Note, the matching changes for Baytrail/Cherrytrail are in the following commit; I'm not sure sure if those platforms are similarly affected. 41656c3dc2ac ASoC: Intel: boards: byt/cht: set card and driver name at run time
Thanks David. I was just looking at 5.10.19 and I don't see any change in SOF. But it may be that the mutual exclusion in sound/soc/sof/intel/Kconfig was not updated. config SND_SOC_SOF_BROADWELL_SUPPORT bool "SOF support for Broadwell" depends on SND_SOC_INTEL_HASWELL=n can you try this diff instead: diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index de7ff2d097ab..6708a2c5a838 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -84,7 +84,7 @@ config SND_SOC_SOF_BAYTRAIL config SND_SOC_SOF_BROADWELL_SUPPORT bool "SOF support for Broadwell" - depends on SND_SOC_INTEL_HASWELL=n + depends on SND_SOC_INTEL_CATPT=n help This adds support for Sound Open Firmware for Intel(R) platforms using the Broadwell processors.
Pierre, Yes, that's exactly the problem. The mutual exclusion worked in kernel 5.9 and earlier, but this change was missing in the Catpt patchset for kernel 5.10. I just confirmed that sound works, and SND_SOC_SOF_BROADWELL is now excluded from the configuration because CONFIG_SND_SOC_INTEL_CATPT=m.
Hello, Thanks quick replies David, and you Pierre for assistance in resolving this. Commit which deprecated haswell and replaced it with catpt: 6cbfa11d2694 ASoC: Intel: Select catpt and deprecate haswell left the old kconfig _HASWELL intact, reducing its functionality to mere delegate: +config SND_SOC_INTEL_HASWELL + tristate + select SND_SOC_INTEL_CATPT so other parts of the code making use of said kconfig needed no immediate changes. What probably happened in v5.10 is distributions updated the kconfig for hsw/bdw audio selecting _CATPT but modifying old _HASWELL from =m to =n. And thus the problem presented itself. To sum up: separate fix (presented by Pierre above) should be send to linux-stable 5.10 and, as SND_SOC_INTEL_HASWELL is no longer in use in newer kernels, it should probably be removed to prevent similar confusion reappearing in the future.
I think you did the right thing Cezary by keeping the old definition, it's not uncommon for some folks to skip multiple versions of kernels but still expect 'make olddefconfig' to keep their selections. There is an implicit backwards-compatibility requirement here and _HASWELL probably needs to remain in the Kconfig for a while. I'll send a patch to alsa-devel and cc:stable later today.
Fixed in kernel 5.10.23: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.23&id=6d7fdad08fbd1d85a79012040f15852763c803c1 Thanks everyone!