| Message ID | 0827a46b8200cc3e053f8fc6b3b428eac90a3618.1483418875.git.mengdong.lin@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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;
> -----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; >
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
>>> 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.
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 >
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
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
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
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;