ASoC driver names
Jaroslav Kysela
perex at perex.cz
Thu Apr 23 13:19:31 CEST 2020
Dne 23. 04. 20 v 13:04 Mark Brown napsal(a):
> On Wed, Apr 22, 2020 at 07:04:36PM +0200, Jaroslav Kysela wrote:
>
>> I am fighting actually with the ASoC driver names. The current situation,
>> where each hardware variant (card name) is mapped to the driver name is not
>> very practical (and not correct). The driver name should describe the common
>> part (usually the controller - like 'HDA-Intel' or bus 'USB-Audio').
>
> With ASoC systems there is no clear controller - you've got a bunch of
> different components, usually connected by separate buses, and it's not
> super obvious what if anything should be the singular name that gets
> picked for some grouping of devices. The whole point of the subsystem
> is to glue a bunch of independent devices together, we've generally
> picked that glue as the driver name.
I refer mostly the top-level code which creates and registers the ASoC card structure.
So it seems the platform name for many ASoC drivers should be there.
>> I am talking about the situation, where the ASoC card name is set via the
>> device tree (snd_soc_of_parse_card_name) like in [1], but the change may be
>> considered for other drivers like Intel SST:
>
>> Card driver name: Lenovo-YOGA-C63
>> Card name: Lenovo-YOGA-C630-13Q50
>> Card long name: LENOVO-81JL-LenovoYOGAC630_13Q50-LNVNB161216
>
>> My question is, can we change / add the more apropriate driver names
>> conditionally with a new kernel CONFIG option? Will you accept this change?
>
> Without knowing what you're actually proposing it's hard to know, and
> there is the risk of userspace breakage here when you change things
> people are relying on.
I propose to set the snd_soc_card->driver_name to something more driver
(not card name) related like:
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index b2de65c7f95c..f6adc5a05eeb 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -557,6 +557,9 @@ static int sdm845_snd_platform_probe(struct platform_device *pdev)
card->dapm_widgets = sdm845_snd_widgets;
card->num_dapm_widgets = ARRAY_SIZE(sdm845_snd_widgets);
card->dev = dev;
+#ifdef CONFIG_SND_SOC_DRIVER_NAMES
+ card->driver_name = "SDM845";
+#endif
dev_set_drvdata(dev, card);
ret = qcom_snd_parse_of(card);
if (ret) {
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 843b8b1c89d4..fdf2c4a12e52 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2246,6 +2246,14 @@ int snd_soc_register_card(struct snd_soc_card *card)
if (!card->name || !card->dev)
return -EINVAL;
+#ifdef CONFIG_SND_SOC_DRIVER_NAMES
+ if (!card->driver_name) {
+ dev_warn(card->dev,
+ "ASoC: Card driver does not set the driver name\n");
+ return -EINVAL;
+ }
+#endif
+
dev_set_drvdata(card->dev, card);
INIT_LIST_HEAD(&card->widgets);
>> The goal is to group the related UCM2 configurations and do the required
>> split inside the UCM2 top-level configuration file based on card components
>> string or other card identificators (related to the driver).
>
> This sounds like you either want some enumeration of the card components
> or perhaps you're looking for some for some indication of the reference
> design that an individual board is based off so you can have a generic
> configuration for that reference design and then override bits of it?
I'd like to group the related configuration files and it seems that the driver
name field in the CTL info structure is misused (duplicate information).
Jaroslav
--
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
More information about the Alsa-devel
mailing list