| Message ID | 20191119174933.25526-2-perex@perex.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] ASoC: add control components management | expand |
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?
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
>>> +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/f1c0083483e184eb7a5eee1f7d8cb4df66cac085 Jaroslav
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
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
> 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)?
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;
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(-)