[alsa-devel] [PATCH 0/5] ASoC: Allow topology to create DAI links
From: Mengdong Lin mengdong.lin@linux.intel.com
This series allows DAI links to be created from topology info.
The components with topology info can come in two ways: - As a component for cpu dai or codec dai of a DAI link predefined by machine driver. - As a auxiliary components defined by the machine driver for a soc card. For this case, the machine driver even need not define any DAI links.
The ASoC core will find and probe these components when instantiating the soc card. When probing the components, topology info will be loaded and DAI links can be created by the topology core. And then ASoC core will find and bind new DAI links after probing the components.
We implement a DAI link list and define API for adding/removing DAI links from topology.
Mengdong Lin (5): ASoC: Implement DAI links in a list & define API to add/remove a link ASoC: Define add/remove_dai_link ops for a soc card ASoC: soc_bind_dai_link() directly returns success for a bound DAI link ASoC: Bind new DAI links after probing components ASoC: The soc card can have auxiliary components
include/sound/soc.h | 29 +++++++++- sound/soc/soc-core.c | 153 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+), 2 deletions(-)
From: Mengdong Lin mengdong.lin@linux.intel.com
Implement a dai link list for the soc card.
Add APIs to add/remove a DAI links dynamically, e.g. by topology.
And a dobj is embedded into the struct snd_soc_dai_link. Topology can use the dobj to find the links created by it and remove them when the topology component is unloaded.
The predefined DAI links are reserved to keep backward compatibility. And they will also be added to the list.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com
diff --git a/include/sound/soc.h b/include/sound/soc.h index 03431e7..d1583df 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1040,6 +1040,9 @@ struct snd_soc_dai_link {
/* pmdown_time is ignored at stop */ unsigned int ignore_pmdown_time:1; + + struct list_head list; /* DAI link list of the soc card */ + struct snd_soc_dobj dobj; /* For topology */ };
struct snd_soc_codec_conf { @@ -1107,8 +1110,11 @@ struct snd_soc_card { long pmdown_time;
/* CPU <--> Codec DAI links */ - struct snd_soc_dai_link *dai_link; - int num_links; + struct snd_soc_dai_link *dai_link; /* predefined links only */ + int num_links; /* predefined links only */ + struct list_head dai_link_list; /* all links */ + int num_dai_links; + struct list_head rtd_list; int num_rtd;
@@ -1652,6 +1658,11 @@ int snd_soc_of_get_dai_link_codecs(struct device *dev, struct device_node *of_node, struct snd_soc_dai_link *dai_link);
+int snd_soc_add_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link); +void snd_soc_remove_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link); + #include <sound/soc-dai.h>
#ifdef CONFIG_DEBUG_FS diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 40682b0..679379d 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1120,6 +1120,7 @@ static void soc_remove_dai_links(struct snd_soc_card *card) { int order; struct snd_soc_pcm_runtime *rtd; + struct snd_soc_dai_link *link, *_link;
for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST; order++) { @@ -1132,6 +1133,15 @@ static void soc_remove_dai_links(struct snd_soc_card *card) list_for_each_entry(rtd, &card->rtd_list, list) soc_remove_link_components(card, rtd, order); } + + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { + if (link->dobj.type == SND_SOC_DOBJ_DAI_LINK) + dev_warn(card->dev, "Topology forgot to remove link %s?\n", + link->name); + + list_del(&link->list); + card->num_dai_links--; + } }
static int snd_soc_init_multicodec(struct snd_soc_card *card, @@ -1228,6 +1238,68 @@ static int soc_init_dai_link(struct snd_soc_card *card, return 0; }
+/** + * snd_soc_add_dai_link - Add a DAI link dynamically + * @card: The ASoC card to which the DAI link is added + * @dai_link: The new DAI link to add + * + * This function adds a DAI link to the ASoC card's link list. + * + * Note: Topology can use this API to add DAI links when probing the + * topology component. And machine drivers can still define static + * DAI links in dai_link array. + */ +int snd_soc_add_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link) +{ + if (dai_link->dobj.type + && dai_link->dobj.type != SND_SOC_DOBJ_DAI_LINK) { + dev_err(card->dev, "Invalid dai link type %d\n", + dai_link->dobj.type); + return -EINVAL; + } + + lockdep_assert_held(&client_mutex); + list_add_tail(&dai_link->list, &card->dai_link_list); + card->num_dai_links++; + + return 0; +} +EXPORT_SYMBOL_GPL(snd_soc_add_dai_link); + +/** + * snd_soc_remove_dai_link - Remove a DAI link from the list + * @card: The ASoC card that owns the link + * @dai_link: The DAI link to remove + * + * This function removes a DAI link from the ASoC card's link list. + * + * For DAI links previously added by topology, topology should + * remove them by using the dobj embedded in the link. + */ +void snd_soc_remove_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link) +{ + struct snd_soc_dai_link *link, *_link; + + if (dai_link->dobj.type + && dai_link->dobj.type != SND_SOC_DOBJ_DAI_LINK) { + dev_err(card->dev, "Invalid dai link type %d\n", + dai_link->dobj.type); + return; + } + + lockdep_assert_held(&client_mutex); + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { + if (link == dai_link) { + list_del(&link->list); + card->num_dai_links--; + return; + } + } +} +EXPORT_SYMBOL_GPL(snd_soc_remove_dai_link); + static void soc_set_name_prefix(struct snd_soc_card *card, struct snd_soc_component *component) { @@ -1722,6 +1794,10 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) goto base_error; }
+ /* add predefined DAI links to the list */ + for (i = 0; i < card->num_links; i++) + snd_soc_add_dai_link(card, card->dai_link+i); + /* initialize the register cache for each available codec */ list_for_each_entry(codec, &codec_list, list) { if (codec->cache_init) @@ -2479,6 +2555,9 @@ int snd_soc_register_card(struct snd_soc_card *card)
snd_soc_initialize_card_lists(card);
+ INIT_LIST_HEAD(&card->dai_link_list); + card->num_dai_links = 0; + INIT_LIST_HEAD(&card->rtd_list); card->num_rtd = 0;
On Wed, Dec 02, 2015 at 02:11:22PM +0800, mengdong.lin@linux.intel.com wrote:
- struct list_head dai_link_list; /* all links */
- int num_dai_links;
Why do we have num_dai_links? I can't see any users.
The patch
ASoC: Implement DAI links in a list & define API to add/remove a link
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
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 f8f80361d07d503093940097e967a7edaa134ca2 Mon Sep 17 00:00:00 2001
From: Mengdong Lin mengdong.lin@linux.intel.com Date: Wed, 2 Dec 2015 14:11:22 +0800 Subject: [PATCH] ASoC: Implement DAI links in a list & define API to add/remove a link
Implement a dai link list for the soc card.
Add APIs to add/remove a DAI links dynamically, e.g. by topology.
And a dobj is embedded into the struct snd_soc_dai_link. Topology can use the dobj to find the links created by it and remove them when the topology component is unloaded.
The predefined DAI links are reserved to keep backward compatibility. And they will also be added to the list.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com Signed-off-by: Mark Brown broonie@kernel.org --- include/sound/soc.h | 15 ++++++++-- sound/soc/soc-core.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h index 232b30d3fa68..410cb0b422be 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1037,6 +1037,9 @@ struct snd_soc_dai_link {
/* pmdown_time is ignored at stop */ unsigned int ignore_pmdown_time:1; + + struct list_head list; /* DAI link list of the soc card */ + struct snd_soc_dobj dobj; /* For topology */ };
struct snd_soc_codec_conf { @@ -1104,8 +1107,11 @@ struct snd_soc_card { long pmdown_time;
/* CPU <--> Codec DAI links */ - struct snd_soc_dai_link *dai_link; - int num_links; + struct snd_soc_dai_link *dai_link; /* predefined links only */ + int num_links; /* predefined links only */ + struct list_head dai_link_list; /* all links */ + int num_dai_links; + struct list_head rtd_list; int num_rtd;
@@ -1647,6 +1653,11 @@ int snd_soc_of_get_dai_link_codecs(struct device *dev, struct device_node *of_node, struct snd_soc_dai_link *dai_link);
+int snd_soc_add_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link); +void snd_soc_remove_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link); + #include <sound/soc-dai.h>
#ifdef CONFIG_DEBUG_FS diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 878a9fe92686..bf4bccfc4b91 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1120,6 +1120,7 @@ static void soc_remove_dai_links(struct snd_soc_card *card) { int order; struct snd_soc_pcm_runtime *rtd; + struct snd_soc_dai_link *link, *_link;
for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST; order++) { @@ -1132,6 +1133,15 @@ static void soc_remove_dai_links(struct snd_soc_card *card) list_for_each_entry(rtd, &card->rtd_list, list) soc_remove_link_components(card, rtd, order); } + + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { + if (link->dobj.type == SND_SOC_DOBJ_DAI_LINK) + dev_warn(card->dev, "Topology forgot to remove link %s?\n", + link->name); + + list_del(&link->list); + card->num_dai_links--; + } }
static int snd_soc_init_multicodec(struct snd_soc_card *card, @@ -1228,6 +1238,68 @@ static int soc_init_dai_link(struct snd_soc_card *card, return 0; }
+/** + * snd_soc_add_dai_link - Add a DAI link dynamically + * @card: The ASoC card to which the DAI link is added + * @dai_link: The new DAI link to add + * + * This function adds a DAI link to the ASoC card's link list. + * + * Note: Topology can use this API to add DAI links when probing the + * topology component. And machine drivers can still define static + * DAI links in dai_link array. + */ +int snd_soc_add_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link) +{ + if (dai_link->dobj.type + && dai_link->dobj.type != SND_SOC_DOBJ_DAI_LINK) { + dev_err(card->dev, "Invalid dai link type %d\n", + dai_link->dobj.type); + return -EINVAL; + } + + lockdep_assert_held(&client_mutex); + list_add_tail(&dai_link->list, &card->dai_link_list); + card->num_dai_links++; + + return 0; +} +EXPORT_SYMBOL_GPL(snd_soc_add_dai_link); + +/** + * snd_soc_remove_dai_link - Remove a DAI link from the list + * @card: The ASoC card that owns the link + * @dai_link: The DAI link to remove + * + * This function removes a DAI link from the ASoC card's link list. + * + * For DAI links previously added by topology, topology should + * remove them by using the dobj embedded in the link. + */ +void snd_soc_remove_dai_link(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link) +{ + struct snd_soc_dai_link *link, *_link; + + if (dai_link->dobj.type + && dai_link->dobj.type != SND_SOC_DOBJ_DAI_LINK) { + dev_err(card->dev, "Invalid dai link type %d\n", + dai_link->dobj.type); + return; + } + + lockdep_assert_held(&client_mutex); + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { + if (link == dai_link) { + list_del(&link->list); + card->num_dai_links--; + return; + } + } +} +EXPORT_SYMBOL_GPL(snd_soc_remove_dai_link); + static void soc_set_name_prefix(struct snd_soc_card *card, struct snd_soc_component *component) { @@ -1722,6 +1794,10 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) goto base_error; }
+ /* add predefined DAI links to the list */ + for (i = 0; i < card->num_links; i++) + snd_soc_add_dai_link(card, card->dai_link+i); + /* initialize the register cache for each available codec */ list_for_each_entry(codec, &codec_list, list) { if (codec->cache_init) @@ -2479,6 +2555,9 @@ int snd_soc_register_card(struct snd_soc_card *card)
snd_soc_initialize_card_lists(card);
+ INIT_LIST_HEAD(&card->dai_link_list); + card->num_dai_links = 0; + INIT_LIST_HEAD(&card->rtd_list); card->num_rtd = 0;
From: Mengdong Lin mengdong.lin@linux.intel.com
A machine driver can register the two ops.
When a DAI link is added or removed by a component's topology, the ASoC core can call the ops to notify the machine driver for extra intialization or destruction.
E.g. topology can create FE DAI links from a cpu DAI component, and the machine driver may define an add_dai_link ops to set machine-specific .init ops for the DAI link.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com
diff --git a/include/sound/soc.h b/include/sound/soc.h index d1583df..f28b36e 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1107,6 +1107,11 @@ struct snd_soc_card { struct snd_soc_dapm_context *dapm, enum snd_soc_bias_level level);
+ int (*add_dai_link)(struct snd_soc_card *, + struct snd_soc_dai_link *link); + void (*remove_dai_link)(struct snd_soc_card *, + struct snd_soc_dai_link *link); + long pmdown_time;
/* CPU <--> Codec DAI links */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 679379d..c504d04 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1260,6 +1260,12 @@ int snd_soc_add_dai_link(struct snd_soc_card *card, }
lockdep_assert_held(&client_mutex); + /* Notify the machine driver for extra initialization + * on the link created by topology. + */ + if (dai_link->dobj.type && card->add_dai_link) + card->add_dai_link(card, dai_link); + list_add_tail(&dai_link->list, &card->dai_link_list); card->num_dai_links++;
@@ -1290,6 +1296,12 @@ void snd_soc_remove_dai_link(struct snd_soc_card *card, }
lockdep_assert_held(&client_mutex); + /* Notify the machine driver for extra destruction + * on the link created by topology. + */ + if (dai_link->dobj.type && card->remove_dai_link) + card->remove_dai_link(card, dai_link); + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { if (link == dai_link) { list_del(&link->list);
The patch
ASoC: Define add/remove_dai_link ops for a soc card
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
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 d6f220ea13edfd3430fb42e09ff92e321ffb5762 Mon Sep 17 00:00:00 2001
From: Mengdong Lin mengdong.lin@linux.intel.com Date: Wed, 2 Dec 2015 14:11:32 +0800 Subject: [PATCH] ASoC: Define add/remove_dai_link ops for a soc card
A machine driver can register the two ops.
When a DAI link is added or removed by a component's topology, the ASoC core can call the ops to notify the machine driver for extra intialization or destruction.
E.g. topology can create FE DAI links from a cpu DAI component, and the machine driver may define an add_dai_link ops to set machine-specific .init ops for the DAI link.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com Signed-off-by: Mark Brown broonie@kernel.org --- include/sound/soc.h | 5 +++++ sound/soc/soc-core.c | 12 ++++++++++++ 2 files changed, 17 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h index 410cb0b422be..af347bcdc2f6 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1104,6 +1104,11 @@ struct snd_soc_card { struct snd_soc_dapm_context *dapm, enum snd_soc_bias_level level);
+ int (*add_dai_link)(struct snd_soc_card *, + struct snd_soc_dai_link *link); + void (*remove_dai_link)(struct snd_soc_card *, + struct snd_soc_dai_link *link); + long pmdown_time;
/* CPU <--> Codec DAI links */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index bf4bccfc4b91..094856fa8cec 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1260,6 +1260,12 @@ int snd_soc_add_dai_link(struct snd_soc_card *card, }
lockdep_assert_held(&client_mutex); + /* Notify the machine driver for extra initialization + * on the link created by topology. + */ + if (dai_link->dobj.type && card->add_dai_link) + card->add_dai_link(card, dai_link); + list_add_tail(&dai_link->list, &card->dai_link_list); card->num_dai_links++;
@@ -1290,6 +1296,12 @@ void snd_soc_remove_dai_link(struct snd_soc_card *card, }
lockdep_assert_held(&client_mutex); + /* Notify the machine driver for extra destruction + * on the link created by topology. + */ + if (dai_link->dobj.type && card->remove_dai_link) + card->remove_dai_link(card, dai_link); + list_for_each_entry_safe(link, _link, &card->dai_link_list, list) { if (link == dai_link) { list_del(&link->list);
From: Mengdong Lin mengdong.lin@linux.intel.com
This function will return success immediately for a bound DAI link. No need to look for the cpu/codec DAIs again.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c504d04..9dada21 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -960,6 +960,19 @@ static struct snd_soc_dai *snd_soc_find_dai( return NULL; }
+static bool soc_is_dai_link_bound(struct snd_soc_card *card, + struct snd_soc_dai_link *dai_link) +{ + struct snd_soc_pcm_runtime *rtd; + + list_for_each_entry(rtd, &card->rtd_list, list) { + if (rtd->dai_link == dai_link) + return true; + } + + return false; +} + static int soc_bind_dai_link(struct snd_soc_card *card, struct snd_soc_dai_link *dai_link) { @@ -977,6 +990,12 @@ static int soc_bind_dai_link(struct snd_soc_card *card, if (!rtd) return -ENOMEM;
+ if (soc_is_dai_link_bound(card, dai_link)) { + dev_dbg(card->dev, "ASoC: dai link %s already bound\n", + dai_link->name); + return 0; + } + cpu_dai_component.name = dai_link->cpu_name; cpu_dai_component.of_node = dai_link->cpu_of_node; cpu_dai_component.dai_name = dai_link->cpu_dai_name;
From: Mengdong Lin mengdong.lin@linux.intel.com
Probing components can bring new DAI or DAI links based on the topology info. This patch finds the unbound DAI links and bind them.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 9dada21..19f7486 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1806,6 +1806,7 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) { struct snd_soc_codec *codec; struct snd_soc_pcm_runtime *rtd; + struct snd_soc_dai_link *dai_link; int ret, i, order;
mutex_lock(&client_mutex); @@ -1893,6 +1894,21 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) } }
+ /* Find new DAI links added during probing components and bind them. + * Components with topology may bring new DAIs and DAI links. + */ + list_for_each_entry(dai_link, &card->dai_link_list, list) { + if (soc_is_dai_link_bound(card, dai_link)) + continue; + + ret = soc_init_dai_link(card, dai_link); + if (ret) + goto probe_dai_err; + ret = soc_bind_dai_link(card, dai_link); + if (ret) + goto probe_dai_err; + } + /* probe all DAI links on this card */ for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST; order++) {
From: Mengdong Lin mengdong.lin@linux.intel.com
Machine drivers can set the name of one or more auxiliary components. And the ASoC core will find and probe the auxiliary components.
Machine drivers can use this to specify the components with topology. Then when the components are probed, topology info will be loaded to the core.
Signed-off-by: Mengdong Lin mengdong.lin@linux.intel.com
diff --git a/include/sound/soc.h b/include/sound/soc.h index f28b36e..46c6492 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1074,6 +1074,11 @@ struct snd_soc_aux_dev { int (*init)(struct snd_soc_component *component); };
+struct snd_soc_aux_component { + const char *name; + struct snd_soc_component *comp; +}; + /* SoC card */ struct snd_soc_card { const char *name; @@ -1120,6 +1125,10 @@ struct snd_soc_card { struct list_head dai_link_list; /* all links */ int num_dai_links;
+ /* auxiliary components, e.g. topology */ + struct snd_soc_aux_component *aux_components; + int num_aux_components; + struct list_head rtd_list; int num_rtd;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 19f7486..4ddc5d5 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1826,6 +1826,18 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) goto base_error; }
+ /* find auxiliary components */ + for (i = 0; i < card->num_aux_components; i++) { + card->aux_components[i].comp = + soc_find_component(NULL, card->aux_components[i].name); + if (!card->aux_components[i].comp) { + dev_err(card->dev, "ASoC: Aux component %s not registered\n", + card->aux_components[i].name); + ret = -EPROBE_DEFER; + goto base_error; + } + } + /* add predefined DAI links to the list */ for (i = 0; i < card->num_links; i++) snd_soc_add_dai_link(card, card->dai_link+i); @@ -1880,6 +1892,21 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) goto card_probe_error; }
+ /* probe auxiliary components */ + for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST; + order++) { + for (i = 0; i < card->num_aux_components; i++) { + ret = soc_probe_component(card, + card->aux_components[i].comp); + if (ret < 0) { + dev_err(card->dev, + "ASoC: failed to probe aux component %s %d\n", + card->aux_components[i].name, ret); + goto probe_dai_err; + } + } + } + /* probe all components used by DAI links on this card */ for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST; order++) {
On Wed, Dec 02, 2015 at 02:11:56PM +0800, mengdong.lin@linux.intel.com wrote:
From: Mengdong Lin mengdong.lin@linux.intel.com
Machine drivers can set the name of one or more auxiliary components. And the ASoC core will find and probe the auxiliary components.
Machine drivers can use this to specify the components with topology. Then when the components are probed, topology info will be loaded to the core.
This makes sense as a replacement for the existing aux_devs but this doesn't feel terribly strongly related to the rest of the series and we're not actually doing the transition yet. What's the relationship with dynamic links and what's the plan for transition? There's CODECs that could be transitioned relatively straightforwardly since they have no DAIs and can only be used as aux_devs, it's them I'm mainly thinking of here - the rest will need to wait I fear.
On 12/09/2015 02:58 AM, Mark Brown wrote:
On Wed, Dec 02, 2015 at 02:11:56PM +0800, mengdong.lin@linux.intel.com wrote:
From: Mengdong Lin mengdong.lin@linux.intel.com
Machine drivers can set the name of one or more auxiliary components. And the ASoC core will find and probe the auxiliary components.
Machine drivers can use this to specify the components with topology. Then when the components are probed, topology info will be loaded to the core.
This makes sense as a replacement for the existing aux_devs but this doesn't feel terribly strongly related to the rest of the series and we're not actually doing the transition yet. What's the relationship with dynamic links and what's the plan for transition? There's CODECs that could be transitioned relatively straightforwardly since they have no DAIs and can only be used as aux_devs, it's them I'm mainly thinking of here - the rest will need to wait I fear.
Thanks for your comments!
I have no intention to replace the existing aux_devs with aux_components. The aux_components is not for codecs and has no rtd like aux_dev.
The purpose to introduce aux_components here is to let a soc card to load topology info easier:
E.g. The machine driver may not define any FE DAI links explicitly but specify an aux component. And the platform driver can implement the aux component and let its probe ops to load the topology info. When the ASoC core is instantiating the soc card, it must to find the aux component and probe it (the platform component). Thus the topology info for the platform is loaded and topology core will create widgets/controls/routes/DAIs/DAI links. So after probing the aux components, the ASoC need to check if any new links are created, bind them and create pcm runtimes for them.
Regards Mengdong
On Wed, Dec 09, 2015 at 05:09:31PM +0800, Mengdong Lin wrote:
I have no intention to replace the existing aux_devs with aux_components. The aux_components is not for codecs and has no rtd like aux_dev.
OK, but I do think that's something we *should* be doing as part of the overall move of CODECs to components and it's something that having this change implies we should be doing as an immediate thing since it's the more obvious direct use of the code (as Lars said in reply to the early draft you posted IIRC).
The purpose to introduce aux_components here is to let a soc card to load topology info easier:
E.g. The machine driver may not define any FE DAI links explicitly but specify an aux component. And the platform driver can implement the aux component and let its probe ops to load the topology info. When the ASoC core is instantiating the soc card, it must to find the aux component and probe it (the platform component). Thus the topology info for the platform is loaded and topology core will create widgets/controls/routes/DAIs/DAI links. So after probing the aux components, the ASoC need to check if any new links are created, bind them and create pcm runtimes for them.
I think I'd need to see the code you're proposing here to really comment but I think it sounds like it comes back to the same thing as the above case where we're overall trying to move everything towards uniformly being components.
On 12/10/2015 04:38 AM, Mark Brown wrote:
On Wed, Dec 09, 2015 at 05:09:31PM +0800, Mengdong Lin wrote:
I have no intention to replace the existing aux_devs with aux_components. The aux_components is not for codecs and has no rtd like aux_dev.
OK, but I do think that's something we *should* be doing as part of the overall move of CODECs to components and it's something that having this change implies we should be doing as an immediate thing since it's the more obvious direct use of the code (as Lars said in reply to the early draft you posted IIRC).
My early draft didn't use the aux components, so I'm not sure where to find Lars's comments on this idea.
Please check if my understanding is right?
I guess you want me to replace the "aux_dev" array from the struct snd_soc_card, by an "aux_components" array. And we may replace soc_bind_aux_dev() by soc_find_components(), replace soc_probe/remove_aux_dev() by soc_probe/remove_components. Probably soc_find/prove/remove_components need some adjustment for the the aux devices (DAIless codecs).
And device driver of the these aux_dev need to use snd_soc_register_component() to make it as a component.
The purpose to introduce aux_components here is to let a soc card to load topology info easier:
E.g. The machine driver may not define any FE DAI links explicitly but specify an aux component. And the platform driver can implement the aux component and let its probe ops to load the topology info. When the ASoC core is instantiating the soc card, it must to find the aux component and probe it (the platform component). Thus the topology info for the platform is loaded and topology core will create widgets/controls/routes/DAIs/DAI links. So after probing the aux components, the ASoC need to check if any new links are created, bind them and create pcm runtimes for them.
I think I'd need to see the code you're proposing here to really comment but I think it sounds like it comes back to the same thing as the above case where we're overall trying to move everything towards uniformly being components.
In my test cases, the Broadwell machine driver (sound/soc/intel/boards/broadwell.c) specifies the name an aux component for the soc card:
+static struct snd_soc_aux_component broadwell_topology_components[] = { + /* Platform topology component */ + { + .name = "haswell-pcm-audio", + }, +};
/* broadwell audio machine driver for WPT + RT286S */ static struct snd_soc_card broadwell_rt286 = { .name = "broadwell-rt286", .owner = THIS_MODULE, + .aux_components = broadwell_topology_components, + .num_aux_components = ARRAY_SIZE(broadwell_topology_components), .dai_link = broadwell_rt286_dais, .num_links = ARRAY_SIZE(broadwell_rt286_dais), .controls = broadwell_controls,
Actually, the component "haswell-pcm-audio" is the component name for the platform (sound/soc/intel/haswell/sst-haswell-pcm.c).
When the ASoC core instantiates the soc card, it will find the aux component at first, which is available only after the platform is registered. Then the ASoC will probe the aux component which triggers the platform probe ops and this ops loads the topology info.
Thanks Mengdong
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, Dec 10, 2015 at 06:05:30PM +0800, Mengdong Lin wrote:
On 12/10/2015 04:38 AM, Mark Brown wrote:
OK, but I do think that's something we *should* be doing as part of the overall move of CODECs to components and it's something that having this change implies we should be doing as an immediate thing since it's the more obvious direct use of the code (as Lars said in reply to the early draft you posted IIRC).
My early draft didn't use the aux components, so I'm not sure where to find Lars's comments on this idea.
He replied to some thing you posted by mistake and immediately retracted. Can't remember the subject, sorry.
Please check if my understanding is right?
I guess you want me to replace the "aux_dev" array from the struct snd_soc_card, by an "aux_components" array. And we may replace soc_bind_aux_dev() by soc_find_components(), replace soc_probe/remove_aux_dev() by soc_probe/remove_components. Probably soc_find/prove/remove_components need some adjustment for the the aux devices (DAIless codecs).
And device driver of the these aux_dev need to use snd_soc_register_component() to make it as a component.
Yeah, pretty much. I think we'll have a period where we support both though as any CODEC *could* be used in this way and we're not ready for that yet.
Let me have a look at converting some of the drivers over the weekend.
On 12/12/2015 04:22 AM, Mark Brown wrote:
On Thu, Dec 10, 2015 at 06:05:30PM +0800, Mengdong Lin wrote:
On 12/10/2015 04:38 AM, Mark Brown wrote:
OK, but I do think that's something we *should* be doing as part of the overall move of CODECs to components and it's something that having this change implies we should be doing as an immediate thing since it's the more obvious direct use of the code (as Lars said in reply to the early draft you posted IIRC).
My early draft didn't use the aux components, so I'm not sure where to find Lars's comments on this idea.
He replied to some thing you posted by mistake and immediately retracted. Can't remember the subject, sorry.
Thanks, I found his comments.
Please check if my understanding is right?
I guess you want me to replace the "aux_dev" array from the struct snd_soc_card, by an "aux_components" array. And we may replace soc_bind_aux_dev() by soc_find_components(), replace soc_probe/remove_aux_dev() by soc_probe/remove_components. Probably soc_find/prove/remove_components need some adjustment for the the aux devices (DAIless codecs).
And device driver of the these aux_dev need to use snd_soc_register_component() to make it as a component.
Yeah, pretty much. I think we'll have a period where we support both though as any CODEC *could* be used in this way and we're not ready for that yet.
Let me have a look at converting some of the drivers over the weekend.
I still have some basic questions:
1. What are the typical usages for aux_dev? For CODEC<->CODEC link or external headset detection chip?
In samsung/neo1973_wm8753.c, the aux_dev "dfbmcs320" is to involve the BT sco codec. And this codec provides dai "bt-sco-pcm" for voice via BT. This seems to be the codec-codec link case, the CODEC can have DAIs.
And this seems to be the external headset chip case (DAIless): In rockchip/rockchip_max98090.c, the aux_devs static struct snd_soc_aux_dev rk_98090_headset_dev = { .name = "Headset Chip", .init = rk_98090_headset_init, }; But how can ASoC find the right component registered by codecs/ts3a227e.c? This aux device does not give a codec node or name.
Any other typical usage cases?
2. Why we need the rtd array 'rtd_aux' for the aux_devs? If the codec has DAIs and used by a DAI link, the ASoC will create a rtd for the link.
Thanks Mengdong
ts3a227e.c
Thanks Mengdong
On Tue, Dec 15, 2015 at 04:06:14PM +0800, Mengdong Lin wrote:
I still have some basic questions:
- What are the typical usages for aux_dev? For CODEC<->CODEC link or external headset detection chip?
Neither, it's for analogue devices.
- Why we need the rtd array 'rtd_aux' for the aux_devs? If the codec has DAIs and used by a DAI link, the ASoC will create a rtd
for the link.
There are (or were at the time) assumptions in drivers that there will be a rtd there so it was easier to provide a stub.
On 12/15/2015 07:23 PM, Mark Brown wrote:
On Tue, Dec 15, 2015 at 04:06:14PM +0800, Mengdong Lin wrote:
I still have some basic questions:
- What are the typical usages for aux_dev? For CODEC<->CODEC link or external headset detection chip?
Neither, it's for analogue devices.
Got it. Thanks!
- Why we need the rtd array 'rtd_aux' for the aux_devs? If the codec has DAIs and used by a DAI link, the ASoC will create a rtd
for the link.
There are (or were at the time) assumptions in drivers that there will be a rtd there so it was easier to provide a stub.
Can we remove this rtd array if current driver does not need the stub?
For the replacement of aux_dev by aux_component, can we define like below?
struct snd_soc_aux_component { const char *comp_name; ... no longer assume they're only codecs const char *comp_of_node;
/* machine specific init */ int (*init)(struct snd_soc_component *componnent); };
The ASoC can use the comp_name or comp_of_node to find the components and probe them.
Thanks Mengdong
On Wed, Dec 16, 2015 at 04:33:32PM +0800, Mengdong Lin wrote:
On 12/15/2015 07:23 PM, Mark Brown wrote:
- Why we need the rtd array 'rtd_aux' for the aux_devs? If the codec has DAIs and used by a DAI link, the ASoC will create a rtd
for the link.
There are (or were at the time) assumptions in drivers that there will be a rtd there so it was easier to provide a stub.
Can we remove this rtd array if current driver does not need the stub?
If it's unneeded we should probably remove it. As might be obvious by now I've not yet had time to dig into the code, sorry. I've got two weeks of vacation after today though.
For the replacement of aux_dev by aux_component, can we define like below?
struct snd_soc_aux_component { const char *comp_name; ... no longer assume they're only codecs const char *comp_of_node;
/* machine specific init */ int (*init)(struct snd_soc_component *componnent); };
The ASoC can use the comp_name or comp_of_node to find the components and probe them.
Well, that's just the existing struct with a rename now I look at it - init() already takes a component. Given that can you not just have whatever code was going to use this work with aux_devs as they are now?
Revise the subject.
Could someone clarify if the rtd_aux in struct snd_soc_card is still needed?
We want to replace the aux_dev by aux_component. If the rtd_aux is no longer needed, we can remove the array and it will become easier to handle an aux_dev as a generic component.
Thanks Mengdong
On 12/16/2015 04:33 PM, Mengdong Lin wrote:
On 12/15/2015 07:23 PM, Mark Brown wrote:
On Tue, Dec 15, 2015 at 04:06:14PM +0800, Mengdong Lin wrote:
I still have some basic questions:
- What are the typical usages for aux_dev? For CODEC<->CODEC link or external headset detection chip?
Neither, it's for analogue devices.
Got it. Thanks!
- Why we need the rtd array 'rtd_aux' for the aux_devs? If the codec has DAIs and used by a DAI link, the ASoC will
create a rtd for the link.
There are (or were at the time) assumptions in drivers that there will be a rtd there so it was easier to provide a stub.
Can we remove this rtd array if current driver does not need the stub?
For the replacement of aux_dev by aux_component, can we define like below?
struct snd_soc_aux_component { const char *comp_name; ... no longer assume they're only codecs const char *comp_of_node;
/* machine specific init */ int (*init)(struct snd_soc_component *componnent);};
The ASoC can use the comp_name or comp_of_node to find the components and probe them.
Thanks Mengdong
On Tue, Dec 22, 2015 at 04:15:26PM +0800, Mengdong Lin wrote:
Revise the subject.
Could someone clarify if the rtd_aux in struct snd_soc_card is still needed?
We want to replace the aux_dev by aux_component.
because...?
If the rtd_aux is no longer needed, we can remove the array and it will become easier to handle an aux_dev as a generic component.
We are still using it in the core but nothing outside the core appears to be using it.
participants (3)
-
Mark Brown -
Mengdong Lin -
mengdong.lin＠linux.intel.com