ASoC: Allow topology to create DAI links

From: Mengdong Lin <[email protected]>

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

From: Mengdong Lin <[email protected]>

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.

index 03431e7..d1583df 100644
@@ -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

2.5.0

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: Mengdong Lin <[email protected]>
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.

---
 include/sound/soc.h  | 15 ++++++++--
 sound/soc/soc-core.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 92 insertions(+), 2 deletions(-)

index 232b30d3fa68..410cb0b422be 100644
@@ -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

2.6.2

From: Mengdong Lin <[email protected]>

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.

index d1583df..f28b36e 100644
@@ -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  */

index 679379d..c504d04 100644
@@ -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

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: Mengdong Lin <[email protected]>
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.

---
 include/sound/soc.h  |  5 +++++
 sound/soc/soc-core.c | 12 ++++++++++++
 2 files changed, 17 insertions(+)

index 410cb0b422be..af347bcdc2f6 100644
@@ -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  */

index bf4bccfc4b91..094856fa8cec 100644
@@ -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

From: Mengdong Lin <[email protected]>

This function will return success immediately for a bound DAI link. No need to look for the cpu/codec DAIs again.

index c504d04..9dada21 100644
@@ -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

From: Mengdong Lin <[email protected]>

Probing components can bring new DAI or DAI links based on the topology info. This patch finds the unbound DAI links and bind them.

index 9dada21..19f7486 100644
@@ -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

From: Mengdong Lin <[email protected]>

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.

index f28b36e..46c6492 100644
@@ -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;
 

index 19f7486..4ddc5d5 100644
@@ -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

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

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

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.

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.

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

He replied to some thing you posted by mistake and immediately retracted. Can't remember the subject, sorry.

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.

Thanks, I found his comments.

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

Neither, it's for analogue devices.

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.

Got it. Thanks!

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

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.

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

because...?

We are still using it in the core but nothing outside the core appears to be using it.