[2/2] ASoC: Intel - use control components to describe card config
diff mbox series

Message ID 20191119174933.25526-2-perex@perex.cz
State New
Headers show
Series
  • [1/2] ASoC: add control components management
Related show

Commit Message

Jaroslav Kysela Nov. 19, 2019, 5:49 p.m. UTC
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(-)

Comments

Pierre-Louis Bossart Nov. 19, 2019, 7:12 p.m. UTC | #1
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?
Jaroslav Kysela Nov. 19, 2019, 7:22 p.m. UTC | #2
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
Pierre-Louis Bossart Nov. 19, 2019, 7:39 p.m. UTC | #3
>>> +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.
Jaroslav Kysela Nov. 19, 2019, 8:27 p.m. UTC | #4
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
Takashi Iwai Nov. 19, 2019, 8:37 p.m. UTC | #5
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
Mark Brown Nov. 19, 2019, 8:41 p.m. UTC | #6
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.
Jaroslav Kysela Nov. 19, 2019, 8:47 p.m. UTC | #7
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
Pierre-Louis Bossart Nov. 20, 2019, 12:24 a.m. UTC | #8
> 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)?

Patch
diff mbox series

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;