[v2,1/2] ASoC: core: Add API to use DMI name in sound card long name
diff mbox

Message ID 0827a46b8200cc3e053f8fc6b3b428eac90a3618.1483418875.git.mengdong.lin@linux.intel.com
State New
Headers show

Commit Message

mengdong.lin@linux.intel.com Jan. 3, 2017, 4:58 a.m. UTC
From: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Intel DSP platform drivers are used by many different devices but are
difficult for userspace to differentiate. This patch adds an API to allow
the DMI name to be used in the sound card long name, thereby helping
userspace load the correct UCM configuration. Usually machine drivers
uses their own name as the sound card name (short name), and leave the
long name and driver name blank. This API will use the DMI info like
vendor, product and board to make up the card long name. If the machine
driver has already explicitly set the long name, this API will do nothing.

This patch also allows for further differentiation as many devices that
share the same DMI name i.e. Minnowboards, UP boards may be configured
with different codecs or firmwares. The API supports flavoring the DMI
name into the card longname to provide the extra differentiation required
for these devices.

For Use Case Manager (UCM) in the user space, changing card long name by
this API is backward compatible, since the card name does not change. For
a given sound card, even if there is no device-specific UCM configuration
file that uses the card long name, UCM will fall back to load the default
configuration file that uses the card name.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>

Comments

Liam Girdwood Jan. 3, 2017, 2:40 p.m. UTC | #1
On Tue, 2017-01-03 at 12:58 +0800, mengdong.lin@linux.intel.com wrote:
> From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> 
> Intel DSP platform drivers are used by many different devices but are
> difficult for userspace to differentiate. This patch adds an API to allow
> the DMI name to be used in the sound card long name, thereby helping
> userspace load the correct UCM configuration. Usually machine drivers
> uses their own name as the sound card name (short name), and leave the
> long name and driver name blank. This API will use the DMI info like
> vendor, product and board to make up the card long name. If the machine
> driver has already explicitly set the long name, this API will do nothing.
> 
> This patch also allows for further differentiation as many devices that
> share the same DMI name i.e. Minnowboards, UP boards may be configured
> with different codecs or firmwares. The API supports flavoring the DMI
> name into the card longname to provide the extra differentiation required
> for these devices.
> 
> For Use Case Manager (UCM) in the user space, changing card long name by
> this API is backward compatible, since the card name does not change. For
> a given sound card, even if there is no device-specific UCM configuration
> file that uses the card long name, UCM will fall back to load the default
> configuration file that uses the card name.
> 
> Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
> 
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index 795e6c4..e4f1844 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -497,6 +497,8 @@ void snd_soc_runtime_deactivate(struct snd_soc_pcm_runtime *rtd, int stream);
>  int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
>  	unsigned int dai_fmt);
>  
> +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour);
> +
>  /* Utility functions to get clock rates from various things */
>  int snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots);
>  int snd_soc_params_to_frame_size(struct snd_pcm_hw_params *params);
> @@ -1094,6 +1096,8 @@ struct snd_soc_card {
>  	const char *name;
>  	const char *long_name;
>  	const char *driver_name;
> +	char dmi_longname[80];
> +
>  	struct device *dev;
>  	struct snd_card *snd_card;
>  	struct module *owner;
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index aaab26a..3dbb5aa 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -34,6 +34,7 @@
>  #include <linux/ctype.h>
>  #include <linux/slab.h>
>  #include <linux/of.h>
> +#include <linux/dmi.h>
>  #include <sound/core.h>
>  #include <sound/jack.h>
>  #include <sound/pcm.h>
> @@ -1886,6 +1887,104 @@ int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
>  }
>  EXPORT_SYMBOL_GPL(snd_soc_runtime_set_dai_fmt);
>  
> +
> +/* Only keep number and alphabet characters and a few separator characters.
> + * DMI info often has SPACE and we must trim them, since Use Case Manager in
> + * the user space expects the device-specific configuration files/directories
> + * use the same name as the card long name but Autoconf cannot support SPACE
> + * in file or directory name.
> + */
> +static void trim_special_characters(char *name)
> +{
> +	int i, j = 0;
> +
> +	for (i = 0; name[i]; i++) {
> +		if (isalnum(name[i]) || (name[i] == '.')
> +		    || (name[i] == '-') || (name[i] == '_'))
> +			name[j++] = name[i];
> +	}
> +
> +	name[j] = '\0';
> +}
> +
> +/**
> + * snd_soc_set_dmi_name() - Register DMI names to card
> + * @card: The card to register DMI names
> + * @flavour: The flavour "differentiator" for the card amongst its peers.
> + *
> + * Intel DSP platform drivers are used by many different devices but are
> + * difficult for userspace to differentiate, since machine drivers ususally
> + * use their own name as the card name (short name) and leave the card long
> + * name blank. This function will allow DMI info to be used as the sound
> + * card long name, thereby helping userspace load the correct UCM (Use Case
> + * Manager) configuration. Character '.' are used to separate different DMI
> + * fields like "vendor.product.board".
> + *
> + * Possible card long names may be:
> + * DellInc..XPS139343.0310JH
> + * IntelCorp..BroadwellClientPlatform.WilsonBeachSDS
> + * ASUSTeKCOMPUTERINC..T100TA.T100TA
> + * Circuitco.MinnowboardMaxD0PLATFORM.MinnowBoardMAX
> + * (Please note DMI info can also include '.' after some abbreviation like
> + * "Inc." so you may see double '.' sometimes)
> + *
> + * This function also supports flavoring the card longname to provide
> + * the extra differentiation, like "vendor.product.board.flavor".

I dont think we need vendor (it just makes it too long). The product or
board name should be unique enough for us to load the correct files.

Liam

> + *
> + * We only keep number and alphabet characters and a few separator characters
> + * in the card long name since UCM in the user space uses the card long names
> + * as card configuration directory names and AudoConf cannot support special
> + * charactors like SPACE.
> + *
> + * Returns 0 on success, otherwise a negative error code.
> + */
> +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
> +{
> +	const char *vendor, *product, *board;
> +	char dmi_longname[80];
> +
> +	if (card->long_name)
> +		return 0; /* long name already set by driver or from DMI */
> +
> +	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
> +	if (!vendor) {
> +		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
> +		return 0;
> +	}
> +
> +	product = dmi_get_system_info(DMI_PRODUCT_NAME);
> +	board = dmi_get_system_info(DMI_BOARD_NAME);
> +	if (!board && !product) {
> +		/* fall back to using legacy name */
> +		dev_warn(card->dev, "ASoC: no DMI board/product name!\n");
> +		return 0;
> +	}
> +
> +	/* make up dmi long name as: vendor.product.board */
> +	if (product && board)
> +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> +			 "%s.%s.%s", vendor, product, board);
> +	else
> +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> +			 "%s.%s", vendor, product ? product : board);
> +
> +	/* Add flavour to dmi long name */
> +	if (flavour)
> +		snprintf(card->dmi_longname, sizeof(card->snd_card->longname),
> +			 "%s.%s", dmi_longname, flavour);
> +	else
> +		strncpy(card->dmi_longname, dmi_longname,
> +			sizeof(card->snd_card->longname) - 1);
> +
> +	trim_special_characters(card->dmi_longname);
> +
> +	/* set long name */
> +	card->long_name = card->dmi_longname;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(snd_soc_set_dmi_name);
> +
>  static int snd_soc_instantiate_card(struct snd_soc_card *card)
>  {
>  	struct snd_soc_codec *codec;
Lin, Mengdong Jan. 3, 2017, 3:44 p.m. UTC | #2
> -----Original Message-----
> From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com]
> Sent: Tuesday, January 3, 2017 10:40 PM
> To: mengdong.lin@linux.intel.com
> Cc: alsa-devel@alsa-project.org; broonie@kernel.org; tiwai@suse.de; Lin,
> Mengdong <mengdong.lin@intel.com>; Koul, Vinod <vinod.koul@intel.com>;
> Bossart, Pierre-louis <pierre-louis.bossart@intel.com>
> Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: core: Add API to use DMI name
> in sound card long name
> 
> On Tue, 2017-01-03 at 12:58 +0800, mengdong.lin@linux.intel.com wrote:
> > From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> >
> > Intel DSP platform drivers are used by many different devices but are
> > difficult for userspace to differentiate. This patch adds an API to
> > allow the DMI name to be used in the sound card long name, thereby
> > helping userspace load the correct UCM configuration. Usually machine
> > drivers uses their own name as the sound card name (short name), and
> > leave the long name and driver name blank. This API will use the DMI
> > info like vendor, product and board to make up the card long name. If
> > the machine driver has already explicitly set the long name, this API will do
> nothing.
> >
> > This patch also allows for further differentiation as many devices
> > that share the same DMI name i.e. Minnowboards, UP boards may be
> > configured with different codecs or firmwares. The API supports
> > flavoring the DMI name into the card longname to provide the extra
> > differentiation required for these devices.
> >
> > For Use Case Manager (UCM) in the user space, changing card long name
> > by this API is backward compatible, since the card name does not
> > change. For a given sound card, even if there is no device-specific
> > UCM configuration file that uses the card long name, UCM will fall
> > back to load the default configuration file that uses the card name.
> >
> > Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> > Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
> >
> > diff --git a/include/sound/soc.h b/include/sound/soc.h index
> > 795e6c4..e4f1844 100644
> > --- a/include/sound/soc.h
> > +++ b/include/sound/soc.h
> > @@ -497,6 +497,8 @@ void snd_soc_runtime_deactivate(struct
> > snd_soc_pcm_runtime *rtd, int stream);  int
> snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
> >  	unsigned int dai_fmt);
> >
> > +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char
> > +*flavour);
> > +
> >  /* Utility functions to get clock rates from various things */  int
> > snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots);
> > int snd_soc_params_to_frame_size(struct snd_pcm_hw_params *params);
> @@
> > -1094,6 +1096,8 @@ struct snd_soc_card {
> >  	const char *name;
> >  	const char *long_name;
> >  	const char *driver_name;
> > +	char dmi_longname[80];
> > +
> >  	struct device *dev;
> >  	struct snd_card *snd_card;
> >  	struct module *owner;
> > diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index
> > aaab26a..3dbb5aa 100644
> > --- a/sound/soc/soc-core.c
> > +++ b/sound/soc/soc-core.c
> > @@ -34,6 +34,7 @@
> >  #include <linux/ctype.h>
> >  #include <linux/slab.h>
> >  #include <linux/of.h>
> > +#include <linux/dmi.h>
> >  #include <sound/core.h>
> >  #include <sound/jack.h>
> >  #include <sound/pcm.h>
> > @@ -1886,6 +1887,104 @@ int snd_soc_runtime_set_dai_fmt(struct
> > snd_soc_pcm_runtime *rtd,  }
> > EXPORT_SYMBOL_GPL(snd_soc_runtime_set_dai_fmt);
> >
> > +
> > +/* Only keep number and alphabet characters and a few separator
> characters.
> > + * DMI info often has SPACE and we must trim them, since Use Case
> > +Manager in
> > + * the user space expects the device-specific configuration
> > +files/directories
> > + * use the same name as the card long name but Autoconf cannot
> > +support SPACE
> > + * in file or directory name.
> > + */
> > +static void trim_special_characters(char *name) {
> > +	int i, j = 0;
> > +
> > +	for (i = 0; name[i]; i++) {
> > +		if (isalnum(name[i]) || (name[i] == '.')
> > +		    || (name[i] == '-') || (name[i] == '_'))
> > +			name[j++] = name[i];
> > +	}
> > +
> > +	name[j] = '\0';
> > +}
> > +
> > +/**
> > + * snd_soc_set_dmi_name() - Register DMI names to card
> > + * @card: The card to register DMI names
> > + * @flavour: The flavour "differentiator" for the card amongst its peers.
> > + *
> > + * Intel DSP platform drivers are used by many different devices but
> > +are
> > + * difficult for userspace to differentiate, since machine drivers
> > +ususally
> > + * use their own name as the card name (short name) and leave the
> > +card long
> > + * name blank. This function will allow DMI info to be used as the
> > +sound
> > + * card long name, thereby helping userspace load the correct UCM
> > +(Use Case
> > + * Manager) configuration. Character '.' are used to separate
> > +different DMI
> > + * fields like "vendor.product.board".
> > + *
> > + * Possible card long names may be:
> > + * DellInc..XPS139343.0310JH
> > + * IntelCorp..BroadwellClientPlatform.WilsonBeachSDS
> > + * ASUSTeKCOMPUTERINC..T100TA.T100TA
> > + * Circuitco.MinnowboardMaxD0PLATFORM.MinnowBoardMAX
> > + * (Please note DMI info can also include '.' after some abbreviation
> > +like
> > + * "Inc." so you may see double '.' sometimes)
> > + *
> > + * This function also supports flavoring the card longname to provide
> > + * the extra differentiation, like "vendor.product.board.flavor".
> 
> I dont think we need vendor (it just makes it too long). The product or board
> name should be unique enough for us to load the correct files.
> 
> Liam

Yes, from the sample machines I checked, product or board name are unique. But I feel there might be the risk that two vendors happen to use the same product or board name, e.g. "T100TA".

And if we want to add the vendor field later, we may need to rename existing UCM configuration files and directories, which may be not so easy if those machines are not around us.

Thanks
Mengdong

> 
> > + *
> > + * We only keep number and alphabet characters and a few separator
> > +characters
> > + * in the card long name since UCM in the user space uses the card
> > +long names
> > + * as card configuration directory names and AudoConf cannot support
> > +special
> > + * charactors like SPACE.
> > + *
> > + * Returns 0 on success, otherwise a negative error code.
> > + */
> > +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char
> > +*flavour) {
> > +	const char *vendor, *product, *board;
> > +	char dmi_longname[80];
> > +
> > +	if (card->long_name)
> > +		return 0; /* long name already set by driver or from DMI */
> > +
> > +	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
> > +	if (!vendor) {
> > +		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
> > +		return 0;
> > +	}
> > +
> > +	product = dmi_get_system_info(DMI_PRODUCT_NAME);
> > +	board = dmi_get_system_info(DMI_BOARD_NAME);
> > +	if (!board && !product) {
> > +		/* fall back to using legacy name */
> > +		dev_warn(card->dev, "ASoC: no DMI board/product
> name!\n");
> > +		return 0;
> > +	}
> > +
> > +	/* make up dmi long name as: vendor.product.board */
> > +	if (product && board)
> > +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> > +			 "%s.%s.%s", vendor, product, board);
> > +	else
> > +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> > +			 "%s.%s", vendor, product ? product : board);
> > +
> > +	/* Add flavour to dmi long name */
> > +	if (flavour)
> > +		snprintf(card->dmi_longname, sizeof(card->snd_card-
> >longname),
> > +			 "%s.%s", dmi_longname, flavour);
> > +	else
> > +		strncpy(card->dmi_longname, dmi_longname,
> > +			sizeof(card->snd_card->longname) - 1);
> > +
> > +	trim_special_characters(card->dmi_longname);
> > +
> > +	/* set long name */
> > +	card->long_name = card->dmi_longname;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(snd_soc_set_dmi_name);
> > +
> >  static int snd_soc_instantiate_card(struct snd_soc_card *card)  {
> >  	struct snd_soc_codec *codec;
>
Liam Girdwood Jan. 3, 2017, 7:28 p.m. UTC | #3
On Tue, 2017-01-03 at 15:44 +0000, Lin, Mengdong wrote:
> > -----Original Message-----
> > From: Liam Girdwood [mailto:liam.r.girdwood@linux.intel.com]
> > Sent: Tuesday, January 3, 2017 10:40 PM
> > To: mengdong.lin@linux.intel.com
> > Cc: alsa-devel@alsa-project.org; broonie@kernel.org; tiwai@suse.de; Lin,
> > Mengdong <mengdong.lin@intel.com>; Koul, Vinod <vinod.koul@intel.com>;
> > Bossart, Pierre-louis <pierre-louis.bossart@intel.com>
> > Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: core: Add API to use DMI name
> > in sound card long name
> > 
> > On Tue, 2017-01-03 at 12:58 +0800, mengdong.lin@linux.intel.com wrote:
> > > From: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> > >
> > > Intel DSP platform drivers are used by many different devices but are
> > > difficult for userspace to differentiate. This patch adds an API to
> > > allow the DMI name to be used in the sound card long name, thereby
> > > helping userspace load the correct UCM configuration. Usually machine
> > > drivers uses their own name as the sound card name (short name), and
> > > leave the long name and driver name blank. This API will use the DMI
> > > info like vendor, product and board to make up the card long name. If
> > > the machine driver has already explicitly set the long name, this API will do
> > nothing.
> > >
> > > This patch also allows for further differentiation as many devices
> > > that share the same DMI name i.e. Minnowboards, UP boards may be
> > > configured with different codecs or firmwares. The API supports
> > > flavoring the DMI name into the card longname to provide the extra
> > > differentiation required for these devices.
> > >
> > > For Use Case Manager (UCM) in the user space, changing card long name
> > > by this API is backward compatible, since the card name does not
> > > change. For a given sound card, even if there is no device-specific
> > > UCM configuration file that uses the card long name, UCM will fall
> > > back to load the default configuration file that uses the card name.
> > >
> > > Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
> > > Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
> > >
> > > diff --git a/include/sound/soc.h b/include/sound/soc.h index
> > > 795e6c4..e4f1844 100644
> > > --- a/include/sound/soc.h
> > > +++ b/include/sound/soc.h
> > > @@ -497,6 +497,8 @@ void snd_soc_runtime_deactivate(struct
> > > snd_soc_pcm_runtime *rtd, int stream);  int
> > snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
> > >  	unsigned int dai_fmt);
> > >
> > > +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char
> > > +*flavour);
> > > +
> > >  /* Utility functions to get clock rates from various things */  int
> > > snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots);
> > > int snd_soc_params_to_frame_size(struct snd_pcm_hw_params *params);
> > @@
> > > -1094,6 +1096,8 @@ struct snd_soc_card {
> > >  	const char *name;
> > >  	const char *long_name;
> > >  	const char *driver_name;
> > > +	char dmi_longname[80];
> > > +
> > >  	struct device *dev;
> > >  	struct snd_card *snd_card;
> > >  	struct module *owner;
> > > diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index
> > > aaab26a..3dbb5aa 100644
> > > --- a/sound/soc/soc-core.c
> > > +++ b/sound/soc/soc-core.c
> > > @@ -34,6 +34,7 @@
> > >  #include <linux/ctype.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/of.h>
> > > +#include <linux/dmi.h>
> > >  #include <sound/core.h>
> > >  #include <sound/jack.h>
> > >  #include <sound/pcm.h>
> > > @@ -1886,6 +1887,104 @@ int snd_soc_runtime_set_dai_fmt(struct
> > > snd_soc_pcm_runtime *rtd,  }
> > > EXPORT_SYMBOL_GPL(snd_soc_runtime_set_dai_fmt);
> > >
> > > +
> > > +/* Only keep number and alphabet characters and a few separator
> > characters.
> > > + * DMI info often has SPACE and we must trim them, since Use Case
> > > +Manager in
> > > + * the user space expects the device-specific configuration
> > > +files/directories
> > > + * use the same name as the card long name but Autoconf cannot
> > > +support SPACE
> > > + * in file or directory name.
> > > + */
> > > +static void trim_special_characters(char *name) {
> > > +	int i, j = 0;
> > > +
> > > +	for (i = 0; name[i]; i++) {
> > > +		if (isalnum(name[i]) || (name[i] == '.')
> > > +		    || (name[i] == '-') || (name[i] == '_'))
> > > +			name[j++] = name[i];
> > > +	}
> > > +
> > > +	name[j] = '\0';
> > > +}
> > > +
> > > +/**
> > > + * snd_soc_set_dmi_name() - Register DMI names to card
> > > + * @card: The card to register DMI names
> > > + * @flavour: The flavour "differentiator" for the card amongst its peers.
> > > + *
> > > + * Intel DSP platform drivers are used by many different devices but
> > > +are
> > > + * difficult for userspace to differentiate, since machine drivers
> > > +ususally
> > > + * use their own name as the card name (short name) and leave the
> > > +card long
> > > + * name blank. This function will allow DMI info to be used as the
> > > +sound
> > > + * card long name, thereby helping userspace load the correct UCM
> > > +(Use Case
> > > + * Manager) configuration. Character '.' are used to separate
> > > +different DMI
> > > + * fields like "vendor.product.board".
> > > + *
> > > + * Possible card long names may be:
> > > + * DellInc..XPS139343.0310JH
> > > + * IntelCorp..BroadwellClientPlatform.WilsonBeachSDS
> > > + * ASUSTeKCOMPUTERINC..T100TA.T100TA
> > > + * Circuitco.MinnowboardMaxD0PLATFORM.MinnowBoardMAX
> > > + * (Please note DMI info can also include '.' after some abbreviation
> > > +like
> > > + * "Inc." so you may see double '.' sometimes)
> > > + *
> > > + * This function also supports flavoring the card longname to provide
> > > + * the extra differentiation, like "vendor.product.board.flavor".
> > 
> > I dont think we need vendor (it just makes it too long). The product or board
> > name should be unique enough for us to load the correct files.
> > 
> > Liam
> 
> Yes, from the sample machines I checked, product or board name are
> unique. But I feel there might be the risk that two vendors happen to
> use the same product or board name, e.g. "T100TA".

I think this would be problematic from a legal/marketing position from
two different vendors so it would be unlikely.

Liam

> 
> And if we want to add the vendor field later, we may need to rename
> existing UCM configuration files and directories, which may be not so
> easy if those machines are not around us.
> 
> Thanks
> Mengdong
> 
> > 
> > > + *
> > > + * We only keep number and alphabet characters and a few separator
> > > +characters
> > > + * in the card long name since UCM in the user space uses the card
> > > +long names
> > > + * as card configuration directory names and AudoConf cannot support
> > > +special
> > > + * charactors like SPACE.
> > > + *
> > > + * Returns 0 on success, otherwise a negative error code.
> > > + */
> > > +int snd_soc_set_dmi_name(struct snd_soc_card *card, const char
> > > +*flavour) {
> > > +	const char *vendor, *product, *board;
> > > +	char dmi_longname[80];
> > > +
> > > +	if (card->long_name)
> > > +		return 0; /* long name already set by driver or from DMI */
> > > +
> > > +	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
> > > +	if (!vendor) {
> > > +		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
> > > +		return 0;
> > > +	}
> > > +
> > > +	product = dmi_get_system_info(DMI_PRODUCT_NAME);
> > > +	board = dmi_get_system_info(DMI_BOARD_NAME);
> > > +	if (!board && !product) {
> > > +		/* fall back to using legacy name */
> > > +		dev_warn(card->dev, "ASoC: no DMI board/product
> > name!\n");
> > > +		return 0;
> > > +	}
> > > +
> > > +	/* make up dmi long name as: vendor.product.board */
> > > +	if (product && board)
> > > +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> > > +			 "%s.%s.%s", vendor, product, board);
> > > +	else
> > > +		snprintf(dmi_longname, sizeof(card->snd_card->longname),
> > > +			 "%s.%s", vendor, product ? product : board);
> > > +
> > > +	/* Add flavour to dmi long name */
> > > +	if (flavour)
> > > +		snprintf(card->dmi_longname, sizeof(card->snd_card-
> > >longname),
> > > +			 "%s.%s", dmi_longname, flavour);
> > > +	else
> > > +		strncpy(card->dmi_longname, dmi_longname,
> > > +			sizeof(card->snd_card->longname) - 1);
> > > +
> > > +	trim_special_characters(card->dmi_longname);
> > > +
> > > +	/* set long name */
> > > +	card->long_name = card->dmi_longname;
> > > +
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(snd_soc_set_dmi_name);
> > > +
> > >  static int snd_soc_instantiate_card(struct snd_soc_card *card)  {
> > >  	struct snd_soc_codec *codec;
> > 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Pierre-Louis Bossart Jan. 3, 2017, 8:09 p.m. UTC | #4
>>> I dont think we need vendor (it just makes it too long). The product or board
>>> name should be unique enough for us to load the correct files.
>>>
>>> Liam
>> Yes, from the sample machines I checked, product or board name are
>> unique. But I feel there might be the risk that two vendors happen to
>> use the same product or board name, e.g. "T100TA".
> I think this would be problematic from a legal/marketing position from
> two different vendors so it would be unlikely.

Please don't remove the manufacturer name for now...
Some vendors use product names that are indeed unique and easy enough to 
remember, but others like Lenovo use "1952W5R" or "20C3001VHH" (real 
examples you can Google to see I am not making this up). The board name 
can also be "SKG18 t". I really have no appetite for a UCM directory 
called 20C3001VHH.SKG18t :-)
I would also be ready to bet that smaller manufacturers in the Chinese 
ecosystem use similar product names at the DMI level. removing the 
vendor name would likely result in mistakes.
You really want the manufacturer name to make the maintenance of these 
files easier on the rest of us. Sometimes the DMI version field is 
actually more self-explanatory, e.g. "ThinkPad 60" or "ThinkPad 10" for 
the two Lenovo examples, maybe this is something we ought to look at.
mengdong.lin@linux.intel.com Jan. 4, 2017, 7:03 a.m. UTC | #5
On 01/04/2017 04:09 AM, Pierre-Louis Bossart wrote:
>
>>>> I dont think we need vendor (it just makes it too long). The product
>>>> or board
>>>> name should be unique enough for us to load the correct files.
>>>>
>>>> Liam
>>> Yes, from the sample machines I checked, product or board name are
>>> unique. But I feel there might be the risk that two vendors happen to
>>> use the same product or board name, e.g. "T100TA".
>> I think this would be problematic from a legal/marketing position from
>> two different vendors so it would be unlikely.
>
> Please don't remove the manufacturer name for now...
> Some vendors use product names that are indeed unique and easy enough to
> remember, but others like Lenovo use "1952W5R" or "20C3001VHH" (real
> examples you can Google to see I am not making this up). The board name
> can also be "SKG18 t". I really have no appetite for a UCM directory
> called 20C3001VHH.SKG18t :-)
> I would also be ready to bet that smaller manufacturers in the Chinese
> ecosystem use similar product names at the DMI level. removing the
> vendor name would likely result in mistakes.
> You really want the manufacturer name to make the maintenance of these
> files easier on the rest of us. Sometimes the DMI version field is
> actually more self-explanatory, e.g. "ThinkPad 60" or "ThinkPad 10" for
> the two Lenovo examples, maybe this is something we ought to look at.
>
>

So we'll keep the manufacturer name.

And let's put the "Product version" as well if available, Liam?

I also observed Lenovo puts the the user-friendly name in the product 
version like "Thinkpad S5 Yoga 15", while it product name is 
"20DQA00KCD", no self-explanatory.

It seems different manufacturer tend to put self-explanatory name in 
different fields:
Lenovo thinkpad: product version
Dell: product name
ASUS: both product name and board name
Intel: board name

Do we want some table to specify the field we want for major vendors? So 
we may just pick the most valuable DMI field for the card long name, for 
those manufacturers to save the space. But it may not scale if the 
manufacturer change their preference or use different way for different 
product series, since I only checked a few machines by a few vendors.

Also I wonder if we find the key word like "Dell, HP or ASUS", may we 
not use verbatim copy on the vendor name but just use these key words? 
This can also save some space.

Thanks
Mengdong





> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Liam Girdwood Jan. 4, 2017, 9:47 p.m. UTC | #6
On Wed, 2017-01-04 at 15:03 +0800, Mengdong Lin wrote:
> 
> On 01/04/2017 04:09 AM, Pierre-Louis Bossart wrote:
> >
> >>>> I dont think we need vendor (it just makes it too long). The product
> >>>> or board
> >>>> name should be unique enough for us to load the correct files.
> >>>>
> >>>> Liam
> >>> Yes, from the sample machines I checked, product or board name are
> >>> unique. But I feel there might be the risk that two vendors happen to
> >>> use the same product or board name, e.g. "T100TA".
> >> I think this would be problematic from a legal/marketing position from
> >> two different vendors so it would be unlikely.
> >
> > Please don't remove the manufacturer name for now...
> > Some vendors use product names that are indeed unique and easy enough to
> > remember, but others like Lenovo use "1952W5R" or "20C3001VHH" (real
> > examples you can Google to see I am not making this up). The board name
> > can also be "SKG18 t". I really have no appetite for a UCM directory
> > called 20C3001VHH.SKG18t :-)
> > I would also be ready to bet that smaller manufacturers in the Chinese
> > ecosystem use similar product names at the DMI level. removing the
> > vendor name would likely result in mistakes.
> > You really want the manufacturer name to make the maintenance of these
> > files easier on the rest of us. Sometimes the DMI version field is
> > actually more self-explanatory, e.g. "ThinkPad 60" or "ThinkPad 10" for
> > the two Lenovo examples, maybe this is something we ought to look at.
> >
> >
> 
> So we'll keep the manufacturer name.
> 
> And let's put the "Product version" as well if available, Liam?

Yes, lets keep the manufacturer name. I agree with Pierre in that we
dont want meaningless directories names. Creating a directory structures
like  

1) manufacturer/product/board OR
2) manufacturer/product OR
3) manufacturer/board

(2 or 3 if board or product is NULL)

are fine by me and make finding the correct card simpler. You could even
replace the . with / in your longname to save the string conversion
later on.

Liam 
> 
> I also observed Lenovo puts the the user-friendly name in the product 
> version like "Thinkpad S5 Yoga 15", while it product name is 
> "20DQA00KCD", no self-explanatory.
> 
> It seems different manufacturer tend to put self-explanatory name in 
> different fields:
> Lenovo thinkpad: product version
> Dell: product name
> ASUS: both product name and board name
> Intel: board name
> 
> Do we want some table to specify the field we want for major vendors? So 
> we may just pick the most valuable DMI field for the card long name, for 
> those manufacturers to save the space. But it may not scale if the 
> manufacturer change their preference or use different way for different 
> product series, since I only checked a few machines by a few vendors.
> 
> Also I wonder if we find the key word like "Dell, HP or ASUS", may we 
> not use verbatim copy on the vendor name but just use these key words? 
> This can also save some space.
> 
> Thanks
> Mengdong
> 
> 
> 
> 
> 
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
mengdong.lin@linux.intel.com Jan. 6, 2017, 6:07 a.m. UTC | #7
On 01/05/2017 05:47 AM, Liam Girdwood wrote:
> On Wed, 2017-01-04 at 15:03 +0800, Mengdong Lin wrote:
>>
>> On 01/04/2017 04:09 AM, Pierre-Louis Bossart wrote:

>> So we'll keep the manufacturer name.
>>
>> And let's put the "Product version" as well if available, Liam?
>
> Yes, lets keep the manufacturer name. I agree with Pierre in that we
> dont want meaningless directories names.

Okay. Thanks for your confirmation!

> Creating a directory structures
> like
>
> 1) manufacturer/product/board OR
> 2) manufacturer/product OR
> 3) manufacturer/board
>
> (2 or 3 if board or product is NULL)
>
> are fine by me and make finding the correct card simpler. You could even
> replace the . with / in your longname to save the string conversion
> later on.
>
> Liam

May we keep the flat directory structure for UCM files?

For the same manufacturer, its DMI vendor name could change, e.g. "Intel 
Inc." or "Intel Corporation". In addition, there may be changes caused 
by using upper case or low case characters. Since we don't want to 
maintain a mapping table and just do verbatim copy of DMI info, it's 
hard to group all the products/boards of one manufacturer into one UCM 
directory. So I feel it may be better to keep the simple flat directory 
structure.

Thanks
Mengdong
Liam Girdwood Jan. 9, 2017, 11:13 a.m. UTC | #8
On Fri, 2017-01-06 at 14:07 +0800, Mengdong Lin wrote:
> 
> On 01/05/2017 05:47 AM, Liam Girdwood wrote:
> > On Wed, 2017-01-04 at 15:03 +0800, Mengdong Lin wrote:
> >>
> >> On 01/04/2017 04:09 AM, Pierre-Louis Bossart wrote:
> 
> >> So we'll keep the manufacturer name.
> >>
> >> And let's put the "Product version" as well if available, Liam?
> >
> > Yes, lets keep the manufacturer name. I agree with Pierre in that we
> > dont want meaningless directories names.
> 
> Okay. Thanks for your confirmation!
> 
> > Creating a directory structures
> > like
> >
> > 1) manufacturer/product/board OR
> > 2) manufacturer/product OR
> > 3) manufacturer/board
> >
> > (2 or 3 if board or product is NULL)
> >
> > are fine by me and make finding the correct card simpler. You could even
> > replace the . with / in your longname to save the string conversion
> > later on.
> >
> > Liam
> 
> May we keep the flat directory structure for UCM files?

This may lead to really long file names and a very crowded master
directory.

> 
> For the same manufacturer, its DMI vendor name could change, e.g. "Intel 
> Inc." or "Intel Corporation". In addition, there may be changes caused 
> by using upper case or low case characters. Since we don't want to 
> maintain a mapping table and just do verbatim copy of DMI info, it's 
> hard to group all the products/boards of one manufacturer into one UCM 
> directory. So I feel it may be better to keep the simple flat directory 
> structure.

This wont matter if we have > 1 directory for Intel or Dell etc, as it's
obvious in the naming. No mapping needed.

Liam

> 
> Thanks
> Mengdong
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Patch
diff mbox

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 795e6c4..e4f1844 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -497,6 +497,8 @@  void snd_soc_runtime_deactivate(struct snd_soc_pcm_runtime *rtd, int stream);
 int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
 	unsigned int dai_fmt);
 
+int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour);
+
 /* Utility functions to get clock rates from various things */
 int snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots);
 int snd_soc_params_to_frame_size(struct snd_pcm_hw_params *params);
@@ -1094,6 +1096,8 @@  struct snd_soc_card {
 	const char *name;
 	const char *long_name;
 	const char *driver_name;
+	char dmi_longname[80];
+
 	struct device *dev;
 	struct snd_card *snd_card;
 	struct module *owner;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index aaab26a..3dbb5aa 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -34,6 +34,7 @@ 
 #include <linux/ctype.h>
 #include <linux/slab.h>
 #include <linux/of.h>
+#include <linux/dmi.h>
 #include <sound/core.h>
 #include <sound/jack.h>
 #include <sound/pcm.h>
@@ -1886,6 +1887,104 @@  int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd,
 }
 EXPORT_SYMBOL_GPL(snd_soc_runtime_set_dai_fmt);
 
+
+/* Only keep number and alphabet characters and a few separator characters.
+ * DMI info often has SPACE and we must trim them, since Use Case Manager in
+ * the user space expects the device-specific configuration files/directories
+ * use the same name as the card long name but Autoconf cannot support SPACE
+ * in file or directory name.
+ */
+static void trim_special_characters(char *name)
+{
+	int i, j = 0;
+
+	for (i = 0; name[i]; i++) {
+		if (isalnum(name[i]) || (name[i] == '.')
+		    || (name[i] == '-') || (name[i] == '_'))
+			name[j++] = name[i];
+	}
+
+	name[j] = '\0';
+}
+
+/**
+ * snd_soc_set_dmi_name() - Register DMI names to card
+ * @card: The card to register DMI names
+ * @flavour: The flavour "differentiator" for the card amongst its peers.
+ *
+ * Intel DSP platform drivers are used by many different devices but are
+ * difficult for userspace to differentiate, since machine drivers ususally
+ * use their own name as the card name (short name) and leave the card long
+ * name blank. This function will allow DMI info to be used as the sound
+ * card long name, thereby helping userspace load the correct UCM (Use Case
+ * Manager) configuration. Character '.' are used to separate different DMI
+ * fields like "vendor.product.board".
+ *
+ * Possible card long names may be:
+ * DellInc..XPS139343.0310JH
+ * IntelCorp..BroadwellClientPlatform.WilsonBeachSDS
+ * ASUSTeKCOMPUTERINC..T100TA.T100TA
+ * Circuitco.MinnowboardMaxD0PLATFORM.MinnowBoardMAX
+ * (Please note DMI info can also include '.' after some abbreviation like
+ * "Inc." so you may see double '.' sometimes)
+ *
+ * This function also supports flavoring the card longname to provide
+ * the extra differentiation, like "vendor.product.board.flavor".
+ *
+ * We only keep number and alphabet characters and a few separator characters
+ * in the card long name since UCM in the user space uses the card long names
+ * as card configuration directory names and AudoConf cannot support special
+ * charactors like SPACE.
+ *
+ * Returns 0 on success, otherwise a negative error code.
+ */
+int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
+{
+	const char *vendor, *product, *board;
+	char dmi_longname[80];
+
+	if (card->long_name)
+		return 0; /* long name already set by driver or from DMI */
+
+	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
+	if (!vendor) {
+		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
+		return 0;
+	}
+
+	product = dmi_get_system_info(DMI_PRODUCT_NAME);
+	board = dmi_get_system_info(DMI_BOARD_NAME);
+	if (!board && !product) {
+		/* fall back to using legacy name */
+		dev_warn(card->dev, "ASoC: no DMI board/product name!\n");
+		return 0;
+	}
+
+	/* make up dmi long name as: vendor.product.board */
+	if (product && board)
+		snprintf(dmi_longname, sizeof(card->snd_card->longname),
+			 "%s.%s.%s", vendor, product, board);
+	else
+		snprintf(dmi_longname, sizeof(card->snd_card->longname),
+			 "%s.%s", vendor, product ? product : board);
+
+	/* Add flavour to dmi long name */
+	if (flavour)
+		snprintf(card->dmi_longname, sizeof(card->snd_card->longname),
+			 "%s.%s", dmi_longname, flavour);
+	else
+		strncpy(card->dmi_longname, dmi_longname,
+			sizeof(card->snd_card->longname) - 1);
+
+	trim_special_characters(card->dmi_longname);
+
+	/* set long name */
+	card->long_name = card->dmi_longname;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_set_dmi_name);
+
 static int snd_soc_instantiate_card(struct snd_soc_card *card)
 {
 	struct snd_soc_codec *codec;