[alsa-devel] [PATCH 1/2] ASoC: add control components management
This ASCII string can carry additional information about soundcard components or configuration. Add the possibility to set this string via the ASoC card.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Mark Brown broonie@kernel.org --- include/sound/soc.h | 1 + sound/soc/soc-core.c | 13 +++++++++++++ 2 files changed, 14 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h index e0855dc08d30..bd943b5d7d45 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -982,6 +982,7 @@ struct snd_soc_card { const char *name; const char *long_name; const char *driver_name; + const char *components; char dmi_longname[80]; char topology_shortname[32];
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 55014e7ae0d8..b4683d4588ee 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2121,6 +2121,19 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) soc_setup_card_name(card->snd_card->driver, card->driver_name, card->name, 1);
+ if (card->components) { + /* the current implementation of snd_component_add() accepts */ + /* multiple components in the string separated by space, */ + /* but the string collision (identical string) check might */ + /* not work correctly */ + ret = snd_component_add(card->snd_card, card->components); + if (ret < 0) { + dev_err(card->dev, "ASoC: %s snd_component_add() failed: %d\n", + card->name, ret); + goto probe_end; + } + } + if (card->late_probe) { ret = card->late_probe(card); if (ret < 0) {
Use the control interface (field 'components' in the info structure) to pass the I/O configuration details. The long card name might be used in GUI. This information should be hidden.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Mark Brown broonie@kernel.org --- sound/soc/intel/Kconfig | 9 +++++++++ sound/soc/intel/boards/bytcht_es8316.c | 16 ++++++++++++---- sound/soc/intel/boards/bytcr_rt5640.c | 14 +++++++++++--- sound/soc/intel/boards/bytcr_rt5651.c | 26 ++++++++++++++++---------- 4 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index c8de0bb5bed9..3421957adedb 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -47,6 +47,15 @@ config SND_SOC_INTEL_SST_FIRMWARE # Haswell/Broadwell/Baytrail legacy and will be set # when these platforms are enabled
+config SND_SOC_INTEL_USE_CTL_COMPONENTS + bool "Use CTL components for I/O configuration" + help + Some drivers might pass the I/O configuration through the + soundcard's driver name in the control user space API. + The new scheme is to put this information to the components + field in the ALSA's card info structure. Say Y, if you + have ALSA user space version 1.2.2+. + config SND_SOC_INTEL_HASWELL tristate "Haswell/Broadwell Platforms" depends on SND_DMA_SGBUF diff --git a/sound/soc/intel/boards/bytcht_es8316.c b/sound/soc/intel/boards/bytcht_es8316.c index 46612331f5ea..a4d098ef0f57 100644 --- a/sound/soc/intel/boards/bytcht_es8316.c +++ b/sound/soc/intel/boards/bytcht_es8316.c @@ -360,7 +360,7 @@ static struct snd_soc_dai_link byt_cht_es8316_dais[] = {
/* SoC card */ static char codec_name[SND_ACPI_I2C_ID_LEN]; -static char long_name[50]; /* = "bytcht-es8316-*-spk-*-mic" */ +static char config_string[50]; /* = long name or components */
static int byt_cht_es8316_suspend(struct snd_soc_card *card) { @@ -572,11 +572,19 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) } }
- /* register the soc card */ - snprintf(long_name, sizeof(long_name), "bytcht-es8316-%s-spk-%s-mic", +#if IS_ENABLED(CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS) + snprintf(config_string, sizeof(config_string), "cfg-spk:%s cfg-mic:%s", + (quirk & BYT_CHT_ES8316_MONO_SPEAKER) ? "1" : "2", + mic_name[BYT_CHT_ES8316_MAP(quirk)]); + byt_cht_es8316_card.components = config_string; +#else + snprintf(config_string, sizeof(config_string), "bytcht-es8316-%s-spk-%s-mic", (quirk & BYT_CHT_ES8316_MONO_SPEAKER) ? "mono" : "stereo", mic_name[BYT_CHT_ES8316_MAP(quirk)]); - byt_cht_es8316_card.long_name = long_name; + byt_cht_es8316_card.long_name = config_string; +#endif + + /* register the soc card */ snd_soc_card_set_drvdata(&byt_cht_es8316_card, priv);
ret = devm_snd_soc_register_card(dev, &byt_cht_es8316_card); diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 9c1aa4ec9cba..22be0c294e4c 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -1080,7 +1080,7 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = { static char byt_rt5640_codec_name[SND_ACPI_I2C_ID_LEN]; static char byt_rt5640_codec_aif_name[12]; /* = "rt5640-aif[1|2]" */ static char byt_rt5640_cpu_dai_name[10]; /* = "ssp[0|2]-port" */ -static char byt_rt5640_long_name[40]; /* = "bytcr-rt5640-*-spk-*-mic" */ +static char byt_rt5640_config[40]; /* = long name or components */
static int byt_rt5640_suspend(struct snd_soc_card *card) { @@ -1303,12 +1303,20 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) } }
- snprintf(byt_rt5640_long_name, sizeof(byt_rt5640_long_name), +#if IS_ENABLED(CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS) + snprintf(byt_rt5640_config, sizeof(byt_rt5640_config), + "cfg-spk:%s cfg-mic:%s", + (byt_rt5640_quirk & BYT_RT5640_MONO_SPEAKER) ? "1" : "2", + map_name[BYT_RT5640_MAP(byt_rt5640_quirk)]); + byt_rt5640_card.components = byt_rt5640_config; +#else + snprintf(byt_rt5640_config, sizeof(byt_rt5640_config), "bytcr-rt5640-%s-spk-%s-mic", (byt_rt5640_quirk & BYT_RT5640_MONO_SPEAKER) ? "mono" : "stereo", map_name[BYT_RT5640_MAP(byt_rt5640_quirk)]); - byt_rt5640_card.long_name = byt_rt5640_long_name; + byt_rt5640_card.long_name = byt_rt5640_config; +#endif
/* override plaform name, if required */ platform_name = mach->mach_params.platform; diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index 4606f6f582d6..485f91b059fb 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -797,7 +797,7 @@ static struct snd_soc_dai_link byt_rt5651_dais[] = { static char byt_rt5651_codec_name[SND_ACPI_I2C_ID_LEN]; static char byt_rt5651_codec_aif_name[12]; /* = "rt5651-aif[1|2]" */ static char byt_rt5651_cpu_dai_name[10]; /* = "ssp[0|2]-port" */ -static char byt_rt5651_long_name[50]; /* = "bytcr-rt5651-*-spk-*-mic[-swapped-hp]" */ +static char byt_rt5651_config[50]; /* = long name or components */
static int byt_rt5651_suspend(struct snd_soc_card *card) { @@ -876,7 +876,6 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) const char *platform_name; struct acpi_device *adev; struct device *codec_dev; - const char *hp_swapped; bool is_bytcr = false; int ret_val = 0; int dai_index = 0; @@ -1080,17 +1079,24 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) } }
- if (byt_rt5651_quirk & BYT_RT5651_HP_LR_SWAPPED) - hp_swapped = "-hp-swapped"; - else - hp_swapped = ""; - - snprintf(byt_rt5651_long_name, sizeof(byt_rt5651_long_name), +#if IS_ENABLED(CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS) + snprintf(byt_rt5651_config, sizeof(byt_rt5651_config), + "cfg-spk:%s cfg-mic:%s%s", + (byt_rt5651_quirk & BYT_RT5651_MONO_SPEAKER) ? "1" : "2", + mic_name[BYT_RT5651_MAP(byt_rt5651_quirk)], + (byt_rt5651_quirk & BYT_RT5651_HP_LR_SWAPPED) ? + " cfg-hp:lrswap" : ""); + byt_rt5651_card.components = byt_rt5651_config; +#else + snprintf(byt_rt5651_config, sizeof(byt_rt5651_config), "bytcr-rt5651-%s-spk-%s-mic%s", (byt_rt5651_quirk & BYT_RT5651_MONO_SPEAKER) ? "mono" : "stereo", - mic_name[BYT_RT5651_MAP(byt_rt5651_quirk)], hp_swapped); - byt_rt5651_card.long_name = byt_rt5651_long_name; + mic_name[BYT_RT5651_MAP(byt_rt5651_quirk)], + (byt_rt5651_quirk & BYT_RT5651_HP_LR_SWAPPED) ? + "-hp-swapped" : ""); + byt_rt5651_card.long_name = byt_rt5651_config; +#endif
/* override plaform name, if required */ platform_name = mach->mach_params.platform;
On 11/19/19 11:49 AM, Jaroslav Kysela wrote:
Use the control interface (field 'components' in the info structure) to pass the I/O configuration details. The long card name might be used in GUI. This information should be hidden.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Mark Brown broonie@kernel.org
sound/soc/intel/Kconfig | 9 +++++++++ sound/soc/intel/boards/bytcht_es8316.c | 16 ++++++++++++---- sound/soc/intel/boards/bytcr_rt5640.c | 14 +++++++++++--- sound/soc/intel/boards/bytcr_rt5651.c | 26 ++++++++++++++++---------- 4 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index c8de0bb5bed9..3421957adedb 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -47,6 +47,15 @@ config SND_SOC_INTEL_SST_FIRMWARE # Haswell/Broadwell/Baytrail legacy and will be set # when these platforms are enabled
+config SND_SOC_INTEL_USE_CTL_COMPONENTS
- bool "Use CTL components for I/O configuration"
- help
Some drivers might pass the I/O configuration through thesoundcard's driver name in the control user space API.The new scheme is to put this information to the componentsfield in the ALSA's card info structure. Say Y, if youhave ALSA user space version 1.2.2+.
If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
Dne 19. 11. 19 v 20:12 Pierre-Louis Bossart napsal(a):
On 11/19/19 11:49 AM, Jaroslav Kysela wrote:
Use the control interface (field 'components' in the info structure) to pass the I/O configuration details. The long card name might be used in GUI. This information should be hidden.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Mark Brown broonie@kernel.org
sound/soc/intel/Kconfig | 9 +++++++++ sound/soc/intel/boards/bytcht_es8316.c | 16 ++++++++++++---- sound/soc/intel/boards/bytcr_rt5640.c | 14 +++++++++++--- sound/soc/intel/boards/bytcr_rt5651.c | 26 ++++++++++++++++---------- 4 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index c8de0bb5bed9..3421957adedb 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -47,6 +47,15 @@ config SND_SOC_INTEL_SST_FIRMWARE # Haswell/Broadwell/Baytrail legacy and will be set # when these platforms are enabled
+config SND_SOC_INTEL_USE_CTL_COMPONENTS
- bool "Use CTL components for I/O configuration"
- help
Some drivers might pass the I/O configuration through thesoundcard's driver name in the control user space API.The new scheme is to put this information to the componentsfield in the ALSA's card info structure. Say Y, if youhave ALSA user space version 1.2.2+.If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
Jaroslav
+config SND_SOC_INTEL_USE_CTL_COMPONENTS + bool "Use CTL components for I/O configuration" + help + Some drivers might pass the I/O configuration through the + soundcard's driver name in the control user space API. + The new scheme is to put this information to the components + field in the ALSA's card info structure. Say Y, if you + have ALSA user space version 1.2.2+.
If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
I am with you on the idea, it's the transition that worries me. I guess for a distro that would be fine, one would hope that there is a communication between the alsa-lib and the kernel configurations parts, but for a random user there's a chance that they would not select this and not use ucm2 and vice versa.
it's also painful for kernel developers to rely on to-be-released alsa-lib changes, we've been there with SOF and I don't know how many times we had reports of issues related to alsa-lib setup problems. Here it'd be worse since alsa-lib updates would need to be deployed on target devices.
Again I am not against the idea, but anything we can do to reuse friction during the transition will help a great deal.
Dne 19. 11. 19 v 20:39 Pierre-Louis Bossart napsal(a):
+config SND_SOC_INTEL_USE_CTL_COMPONENTS + bool "Use CTL components for I/O configuration" + help + Some drivers might pass the I/O configuration through the + soundcard's driver name in the control user space API. + The new scheme is to put this information to the components + field in the ALSA's card info structure. Say Y, if you + have ALSA user space version 1.2.2+.
If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
I am with you on the idea, it's the transition that worries me. I guess for a distro that would be fine, one would hope that there is a communication between the alsa-lib and the kernel configurations parts, but for a random user there's a chance that they would not select this and not use ucm2 and vice versa.
it's also painful for kernel developers to rely on to-be-released alsa-lib changes, we've been there with SOF and I don't know how many times we had reports of issues related to alsa-lib setup problems.
I think that the most of issues were because there was no stable ucm upstream for SOF. I've seen multiple variants of UCM configuration files for SOF (and everything will be finalized with 5.5 kernel!).
Here it'd be worse since alsa-lib updates would need to be deployed on target devices.
Again I am not against the idea, but anything we can do to reuse friction during the transition will help a great deal.
Thinking more, we can create an ucm2 configuration which will handle both cases (independent on CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS). I prepared an example:
https://github.com/alsa-project/alsa-ucm-conf/commit/f1c0083483e184eb7a5eee1...
Jaroslav
Thinking more, we can create an ucm2 configuration which will handle both cases (independent on CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS). I prepared an example:
https://github.com/alsa-project/alsa-ucm-conf/commit/f1c0083483e184eb7a5eee1...
That'd be fine with me. There's a bit of duplication but it's manageable.
Rather than keep this forever, may we force the use of these components for HDaudio+DMIC devices that are only handled by SOF, starting with 5.5 w/ ucm2, and for older devices BYT/CHT devices ucm2 files are backwards compatible on two levels (SOF or legacy, and longnames or components)?
On Tue, 19 Nov 2019 20:22:56 +0100, Jaroslav Kysela wrote:
Dne 19. 11. 19 v 20:12 Pierre-Louis Bossart napsal(a):
On 11/19/19 11:49 AM, Jaroslav Kysela wrote:
Use the control interface (field 'components' in the info structure) to pass the I/O configuration details. The long card name might be used in GUI. This information should be hidden.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Mark Brown broonie@kernel.org
sound/soc/intel/Kconfig | 9 +++++++++ sound/soc/intel/boards/bytcht_es8316.c | 16 ++++++++++++---- sound/soc/intel/boards/bytcr_rt5640.c | 14 +++++++++++--- sound/soc/intel/boards/bytcr_rt5651.c | 26 ++++++++++++++++---------- 4 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index c8de0bb5bed9..3421957adedb 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -47,6 +47,15 @@ config SND_SOC_INTEL_SST_FIRMWARE # Haswell/Broadwell/Baytrail legacy and will be set # when these platforms are enabled +config SND_SOC_INTEL_USE_CTL_COMPONENTS
- bool "Use CTL components for I/O configuration"
- help
Some drivers might pass the I/O configuration through thesoundcard's driver name in the control user space API.The new scheme is to put this information to the componentsfield in the ALSA's card info structure. Say Y, if youhave ALSA user space version 1.2.2+.If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
But why these are exclusive? The current longname workaround makes the device appearing a bit messy, but does it conflict with the additional component string?
thanks,
Takashi
On Tue, Nov 19, 2019 at 09:37:15PM +0100, Takashi Iwai wrote:
Jaroslav Kysela wrote:
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
But why these are exclusive? The current longname workaround makes the device appearing a bit messy, but does it conflict with the additional component string?
Yeah, it's not clear to me why it's a config option to enable this. I can see a config option to turn off the old display name if it's particularly irritating to people but I can't see any reason not to just provide the new stuff.
Dne 19. 11. 19 v 21:41 Mark Brown napsal(a):
On Tue, Nov 19, 2019 at 09:37:15PM +0100, Takashi Iwai wrote:
Jaroslav Kysela wrote:
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
But why these are exclusive? The current longname workaround makes the device appearing a bit messy, but does it conflict with the additional component string?
Yeah, it's not clear to me why it's a config option to enable this. I can see a config option to turn off the old display name if it's particularly irritating to people but I can't see any reason not to just provide the new stuff.
Yes, it is really better way to do this. I'll rewrite my patch. Thanks for the idea.
Jaroslav
The patch
ASoC: add control components management
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From dc73d73aa7145f55412611f3eead1e85ae026785 Mon Sep 17 00:00:00 2001
From: Jaroslav Kysela perex@perex.cz Date: Tue, 19 Nov 2019 18:49:32 +0100 Subject: [PATCH] ASoC: add control components management
This ASCII string can carry additional information about soundcard components or configuration. Add the possibility to set this string via the ASoC card.
Signed-off-by: Jaroslav Kysela perex@perex.cz Cc: Mark Brown broonie@kernel.org Link: https://lore.kernel.org/r/20191119174933.25526-1-perex@perex.cz Signed-off-by: Mark Brown broonie@kernel.org --- include/sound/soc.h | 1 + sound/soc/soc-core.c | 13 +++++++++++++ 2 files changed, 14 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h index e0855dc08d30..bd943b5d7d45 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -982,6 +982,7 @@ struct snd_soc_card { const char *name; const char *long_name; const char *driver_name; + const char *components; char dmi_longname[80]; char topology_shortname[32];
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index e3a53ef1db04..cc0ef0fcc005 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2108,6 +2108,19 @@ static int snd_soc_bind_card(struct snd_soc_card *card) soc_setup_card_name(card->snd_card->driver, card->driver_name, card->name, 1);
+ if (card->components) { + /* the current implementation of snd_component_add() accepts */ + /* multiple components in the string separated by space, */ + /* but the string collision (identical string) check might */ + /* not work correctly */ + ret = snd_component_add(card->snd_card, card->components); + if (ret < 0) { + dev_err(card->dev, "ASoC: %s snd_component_add() failed: %d\n", + card->name, ret); + goto probe_end; + } + } + if (card->late_probe) { ret = card->late_probe(card); if (ret < 0) {
participants (4)
-
Jaroslav Kysela -
Mark Brown -
Pierre-Louis Bossart -
Takashi Iwai