* [alsa-devel] [PATCH 1/2] ASoC: add control components management @ 2019-11-19 17:49 Jaroslav Kysela 2019-11-19 17:49 ` [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config Jaroslav Kysela 2019-11-20 17:18 ` [alsa-devel] Applied "ASoC: add control components management" to the asoc tree Mark Brown 0 siblings, 2 replies; 11+ messages in thread From: Jaroslav Kysela @ 2019-11-19 17:49 UTC (permalink / raw) To: ALSA development; +Cc: Takashi Iwai, Mark Brown 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 17:49 [alsa-devel] [PATCH 1/2] ASoC: add control components management Jaroslav Kysela @ 2019-11-19 17:49 ` Jaroslav Kysela 2019-11-19 19:12 ` Pierre-Louis Bossart 2019-11-20 17:18 ` [alsa-devel] Applied "ASoC: add control components management" to the asoc tree Mark Brown 1 sibling, 1 reply; 11+ messages in thread From: Jaroslav Kysela @ 2019-11-19 17:49 UTC (permalink / raw) To: ALSA development; +Cc: Takashi Iwai, Mark Brown, Pierre-Louis Bossart 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 17:49 ` [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config Jaroslav Kysela @ 2019-11-19 19:12 ` Pierre-Louis Bossart 2019-11-19 19:22 ` Jaroslav Kysela 0 siblings, 1 reply; 11+ messages in thread From: Pierre-Louis Bossart @ 2019-11-19 19:12 UTC (permalink / raw) To: Jaroslav Kysela, ALSA development; +Cc: Takashi Iwai, Mark Brown 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 19:12 ` Pierre-Louis Bossart @ 2019-11-19 19:22 ` Jaroslav Kysela 2019-11-19 19:39 ` Pierre-Louis Bossart 2019-11-19 20:37 ` Takashi Iwai 0 siblings, 2 replies; 11+ messages in thread From: Jaroslav Kysela @ 2019-11-19 19:22 UTC (permalink / raw) To: Pierre-Louis Bossart, ALSA development; +Cc: Takashi Iwai, Mark Brown 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 19:22 ` Jaroslav Kysela @ 2019-11-19 19:39 ` Pierre-Louis Bossart 2019-11-19 20:27 ` Jaroslav Kysela 2019-11-19 20:37 ` Takashi Iwai 1 sibling, 1 reply; 11+ messages in thread From: Pierre-Louis Bossart @ 2019-11-19 19:39 UTC (permalink / raw) To: Jaroslav Kysela, ALSA development; +Cc: Takashi Iwai, Mark Brown >>> +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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 19:39 ` Pierre-Louis Bossart @ 2019-11-19 20:27 ` Jaroslav Kysela 2019-11-20 0:24 ` Pierre-Louis Bossart 0 siblings, 1 reply; 11+ messages in thread From: Jaroslav Kysela @ 2019-11-19 20:27 UTC (permalink / raw) To: Pierre-Louis Bossart, ALSA development; +Cc: Takashi Iwai, Mark Brown 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 20:27 ` Jaroslav Kysela @ 2019-11-20 0:24 ` Pierre-Louis Bossart 0 siblings, 0 replies; 11+ messages in thread From: Pierre-Louis Bossart @ 2019-11-20 0:24 UTC (permalink / raw) To: Jaroslav Kysela, ALSA development; +Cc: Takashi Iwai, Mark Brown > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 19:22 ` Jaroslav Kysela 2019-11-19 19:39 ` Pierre-Louis Bossart @ 2019-11-19 20:37 ` Takashi Iwai 2019-11-19 20:41 ` Mark Brown 1 sibling, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2019-11-19 20:37 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: ALSA development, Mark Brown, Pierre-Louis Bossart 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 20:37 ` Takashi Iwai @ 2019-11-19 20:41 ` Mark Brown 2019-11-19 20:47 ` Jaroslav Kysela 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2019-11-19 20:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: ALSA development, Pierre-Louis Bossart [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config 2019-11-19 20:41 ` Mark Brown @ 2019-11-19 20:47 ` Jaroslav Kysela 0 siblings, 0 replies; 11+ messages in thread From: Jaroslav Kysela @ 2019-11-19 20:47 UTC (permalink / raw) To: Mark Brown, Takashi Iwai; +Cc: ALSA development, Pierre-Louis Bossart 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [alsa-devel] Applied "ASoC: add control components management" to the asoc tree 2019-11-19 17:49 [alsa-devel] [PATCH 1/2] ASoC: add control components management Jaroslav Kysela 2019-11-19 17:49 ` [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config Jaroslav Kysela @ 2019-11-20 17:18 ` Mark Brown 1 sibling, 0 replies; 11+ messages in thread From: Mark Brown @ 2019-11-20 17:18 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: Takashi Iwai, ALSA development, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-11-20 17:22 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-19 17:49 [alsa-devel] [PATCH 1/2] ASoC: add control components management Jaroslav Kysela 2019-11-19 17:49 ` [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config Jaroslav Kysela 2019-11-19 19:12 ` Pierre-Louis Bossart 2019-11-19 19:22 ` Jaroslav Kysela 2019-11-19 19:39 ` Pierre-Louis Bossart 2019-11-19 20:27 ` Jaroslav Kysela 2019-11-20 0:24 ` Pierre-Louis Bossart 2019-11-19 20:37 ` Takashi Iwai 2019-11-19 20:41 ` Mark Brown 2019-11-19 20:47 ` Jaroslav Kysela 2019-11-20 17:18 ` [alsa-devel] Applied "ASoC: add control components management" to the asoc tree Mark Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.