Bug 211985 - Broadwell audio machine driver uses wrong card name with Catpt driver selected, if SOF enabled at build time
Summary: Broadwell audio machine driver uses wrong card name with Catpt driver selecte...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-27 17:27 UTC by David Ward
Modified: 2021-03-13 17:11 UTC (History)
5 users (show)

See Also:
Kernel Version: 5.10
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
alsa-info.txt with kernel 5.10.16-arch1-1 (35.78 KB, text/plain)
2021-02-27 17:32 UTC, David Ward
Details
alsa-info.txt with kernel 5.10.16-arch1-1-custom (CONFIG_SND_SOC_SOF_BROADWELL=m) (35.52 KB, text/plain)
2021-02-27 17:34 UTC, David Ward
Details

Description David Ward 2021-02-27 17:27:49 UTC
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).
Comment 1 David Ward 2021-02-27 17:32:41 UTC
Created attachment 295507 [details]
alsa-info.txt with kernel 5.10.16-arch1-1
Comment 2 David Ward 2021-02-27 17:34:34 UTC
Created attachment 295509 [details]
alsa-info.txt with kernel 5.10.16-arch1-1-custom (CONFIG_SND_SOC_SOF_BROADWELL=m)
Comment 3 Cezary Rojewski 2021-03-01 11:29:54 UTC
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.
Comment 4 Pierre Bossart 2021-03-01 14:40:00 UTC
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.
Comment 5 David Ward 2021-03-02 13:03:12 UTC
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
Comment 6 Pierre Bossart 2021-03-02 15:04:06 UTC
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.
Comment 7 David Ward 2021-03-02 23:17:56 UTC
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.
Comment 8 Cezary Rojewski 2021-03-03 11:11:10 UTC
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.
Comment 9 Pierre Bossart 2021-03-03 16:50:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.