[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 at perex.cz>
> >> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> >> Cc: Mark Brown <broonie at 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