[PATCH 0/5] ASoC: Allow topology to create DAI links

[PATCH 0/5] ASoC: Allow topology to create DAI links

[mengdong.lin]

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(-)

-- 
2.5.0

[PATCH 1/5] ASoC: Implement DAI links in a list & define API to add/remove a link

[mengdong.lin]

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;
 
-- 
2.5.0

[PATCH 2/5] ASoC: Define add/remove_dai_link ops for a soc card

[mengdong.lin]

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);
-- 
2.5.0

[PATCH 3/5] ASoC: soc_bind_dai_link() directly returns success for a bound DAI link

[mengdong.lin]

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;
-- 
2.5.0

[PATCH 4/5] ASoC: Bind new DAI links after probing components

[mengdong.lin]

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++) {
-- 
2.5.0

[PATCH 5/5] ASoC: The soc card can have auxiliary components

[mengdong.lin]

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++) {
-- 
2.5.0

Re: [PATCH 1/5] ASoC: Implement DAI links in a list & define API to add/remove a link

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 209 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 915 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Applied "ASoC: Define add/remove_dai_link ops for a soc card" to the asoc tree

[Mark Brown]

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);
-- 
2.6.2

Applied "ASoC: Implement DAI links in a list & define API to add/remove a link" to the asoc tree

[Mark Brown]

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;
 
-- 
2.6.2

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mengdong Lin]

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

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mengdong Lin]

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
>

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1399 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mengdong Lin]

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

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 525 bytes --]

On Tue, Dec 15, 2015 at 04:06:14PM +0800, Mengdong Lin wrote:

> I still have some basic questions:

> 1. What are the typical usages for aux_dev?
>    For CODEC<->CODEC link or external headset detection chip?

Neither, it's for analogue devices.

> 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.

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mengdong Lin]

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:
>
>> 1. 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!

>
>> 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.
>
> 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

Re: [PATCH 5/5] ASoC: The soc card can have auxiliary components

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1285 bytes --]

On Wed, Dec 16, 2015 at 04:33:32PM +0800, Mengdong Lin wrote:
> On 12/15/2015 07:23 PM, Mark Brown wrote:

> >>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.

> >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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Can we remove the rtd_aux for the aux_devs?

[Mengdong Lin]

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:
>>
>>> 1. 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!
>
>>
>>> 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.
>>
>> 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
>

Re: Can we remove the rtd_aux for the aux_devs?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 453 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]