[alsa-devel] [PATCH 1/2] ASoC: add control components management

[alsa-devel] [PATCH 1/2] ASoC: add control components management

[Jaroslav Kysela]

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) {
-- 
2.20.1
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Jaroslav Kysela]

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;
-- 
2.20.1
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Pierre-Louis Bossart]

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 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?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Jaroslav Kysela]

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 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.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Pierre-Louis Bossart]

>>> +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.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Jaroslav Kysela]

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/f1c0083483e184eb7a5eee1f7d8cb4df66cac085

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Takashi Iwai]

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 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.

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Jaroslav Kysela]

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

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config

[Pierre-Louis Bossart]

> 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/f1c0083483e184eb7a5eee1f7d8cb4df66cac085 

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)?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[alsa-devel] Applied "ASoC: add control components management" to the asoc tree

[Mark Brown]

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) {
-- 
2.20.1

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel