[PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
file in debugfs, placed in the card's DAPM directory.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
---

Sample output: https://cutebit.org/macaudio-j274.svg
(With unupstreamed sound drivers on Mac mini (2020))

The helper bufprintf macro triggers checkpath.pl:

ERROR: Macros with complex values should be enclosed in parentheses
#47: FILE: sound/soc/soc-dapm.c:2235:
+#define bufprintf(...) \
+               ret += scnprintf(buf + ret, bufsize - ret, __VA_ARGS__)

but adding in {} to the macro body interferes with the if/else
constructions later, so I left it as-is.

 sound/soc/soc-dapm.c | 141 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 73b8bd452ca7..86524908c3fd 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2210,6 +2210,143 @@ static const struct file_operations dapm_bias_fops = {
 	.llseek = default_llseek,
 };
 
+static ssize_t dapm_graph_read_file(struct file *file, char __user *user_buf,
+				    size_t count, loff_t *ppos)
+{
+	struct snd_soc_card *card = file->private_data;
+	struct snd_soc_dapm_context *dapm;
+	struct snd_soc_dapm_path *p;
+	struct snd_soc_dapm_widget *w;
+	struct snd_soc_pcm_runtime *rtd;
+	struct snd_soc_dapm_widget *wdone[16];
+	struct snd_soc_dai *dai;
+	int i, num_wdone = 0, cluster = 0;
+	char *buf;
+	ssize_t bufsize;
+	ssize_t ret = 0;
+
+	bufsize = 1024 * card->num_dapm_widgets;
+	buf = kmalloc(bufsize, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	mutex_lock(&card->dapm_mutex);
+
+#define bufprintf(...) \
+		ret += scnprintf(buf + ret, bufsize - ret, __VA_ARGS__)
+
+	bufprintf("digraph dapm {\n");
+	bufprintf("label=\"%s\";\n", card->name);
+
+	/*
+	 * Print the user-visible PCM devices of the card.
+	 */
+	bufprintf("subgraph cluster_%d {\n", cluster++);
+	bufprintf("label=\"PCM devices\";style=filled;fillcolor=lightgray;\n");
+	for_each_card_rtds(card, rtd) {
+		if (rtd->dai_link->no_pcm)
+			continue;
+
+		bufprintf("w%pK [label=\"%d: %s\"];\n", rtd,
+			  rtd->pcm->device, rtd->dai_link->name);
+	}
+	bufprintf("};\n");
+
+	/*
+	 * Print the playback/capture widgets of CPU-side DAIs, and link
+	 * them to the PCM devices. Keep a list of already printed
+	 * widgets in 'wdone', so they will be skipped later. Do not put
+	 * these widgets in a component cluster like we will do with
+	 * the other widgets later, since that just clutters the graph.
+	 */
+	for_each_card_rtds(card, rtd) {
+		for_each_rtd_cpu_dais(rtd, i, dai) {
+			if (dai->playback_widget) {
+				w = dai->playback_widget;
+				bufprintf("w%pK [label=\"%s\"];\n", w, w->name);
+				if (!rtd->dai_link->no_pcm)
+					bufprintf("w%pK -> w%pK;\n", rtd, w);
+				wdone[num_wdone] = w;
+				if (num_wdone < ARRAY_SIZE(wdone))
+					num_wdone++;
+			}
+
+			if (dai->capture_widget) {
+				w = dai->capture_widget;
+				bufprintf("w%pK [label=\"%s\"];\n", w, w->name);
+				if (!rtd->dai_link->no_pcm)
+					bufprintf("w%pK -> w%pK;\n", w, rtd);
+				wdone[num_wdone] = w;
+				if (num_wdone < ARRAY_SIZE(wdone))
+					num_wdone++;
+			}
+		}
+	}
+
+	for_each_card_dapms(card, dapm) {
+		const char *prefix = soc_dapm_prefix(dapm);
+
+		if (dapm != &card->dapm) {
+			bufprintf("subgraph cluster_%d {\n", cluster++);
+			if (prefix && dapm->component)
+				bufprintf("label=\"%s (%s)\";\n", prefix,
+					  dapm->component->name);
+			else if (dapm->component)
+				bufprintf("label=\"%s\";\n",
+					  dapm->component->name);
+		}
+
+		for_each_card_widgets(dapm->card, w) {
+			const char *name = w->name;
+			bool skip = false;
+
+			if (w->dapm != dapm)
+				continue;
+
+			if (list_empty(&w->edges[0]) && list_empty(&w->edges[1]))
+				continue;
+
+			for (i = 0; i < num_wdone; i++)
+				if (wdone[i] == w)
+					skip = true;
+			if (skip)
+				continue;
+
+			if (prefix && strlen(name) > strlen(prefix) + 1)
+				name += strlen(prefix) + 1;
+
+			bufprintf("w%pK [label=\"%s\"];\n", w, name);
+		}
+
+		if (dapm != &card->dapm)
+			bufprintf("}\n");
+	}
+
+	list_for_each_entry(p, &card->paths, list) {
+		if (p->name)
+			bufprintf("w%pK -> w%pK [label=\"%s\"];\n",
+				  p->source, p->sink, p->name);
+		else
+			bufprintf("w%pK -> w%pK;\n", p->source, p->sink);
+	}
+
+	bufprintf("}\n");
+#undef bufprintf
+
+	mutex_unlock(&card->dapm_mutex);
+
+	ret = simple_read_from_buffer(user_buf, count, ppos, buf, ret);
+
+	kfree(buf);
+	return ret;
+}
+
+static const struct file_operations dapm_graph_fops = {
+	.open = simple_open,
+	.read = dapm_graph_read_file,
+	.llseek = default_llseek,
+};
+
 void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm,
 	struct dentry *parent)
 {
@@ -2220,6 +2357,10 @@ void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm,
 
 	debugfs_create_file("bias_level", 0444, dapm->debugfs_dapm, dapm,
 			    &dapm_bias_fops);
+
+	if (dapm == &dapm->card->dapm)
+		debugfs_create_file("graph.dot", 0444, dapm->debugfs_dapm,
+				    dapm->card, &dapm_graph_fops);
 }
 
 static void dapm_debugfs_add_widget(struct snd_soc_dapm_widget *w)
-- 
2.33.0

[PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
file in debugfs, placed in the card's DAPM directory.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
---

Sample output: https://cutebit.org/macaudio-j274.svg
(With unupstreamed sound drivers on Mac mini (2020))

The helper bufprintf macro triggers checkpath.pl:

ERROR: Macros with complex values should be enclosed in parentheses
#47: FILE: sound/soc/soc-dapm.c:2235:
+#define bufprintf(...) \
+               ret += scnprintf(buf + ret, bufsize - ret, __VA_ARGS__)

but adding in {} to the macro body interferes with the if/else
constructions later, so I left it as-is.

 sound/soc/soc-dapm.c | 141 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 73b8bd452ca7..86524908c3fd 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2210,6 +2210,143 @@ static const struct file_operations dapm_bias_fops = {
 	.llseek = default_llseek,
 };
 
+static ssize_t dapm_graph_read_file(struct file *file, char __user *user_buf,
+				    size_t count, loff_t *ppos)
+{
+	struct snd_soc_card *card = file->private_data;
+	struct snd_soc_dapm_context *dapm;
+	struct snd_soc_dapm_path *p;
+	struct snd_soc_dapm_widget *w;
+	struct snd_soc_pcm_runtime *rtd;
+	struct snd_soc_dapm_widget *wdone[16];
+	struct snd_soc_dai *dai;
+	int i, num_wdone = 0, cluster = 0;
+	char *buf;
+	ssize_t bufsize;
+	ssize_t ret = 0;
+
+	bufsize = 1024 * card->num_dapm_widgets;
+	buf = kmalloc(bufsize, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	mutex_lock(&card->dapm_mutex);
+
+#define bufprintf(...) \
+		ret += scnprintf(buf + ret, bufsize - ret, __VA_ARGS__)
+
+	bufprintf("digraph dapm {\n");
+	bufprintf("label=\"%s\";\n", card->name);
+
+	/*
+	 * Print the user-visible PCM devices of the card.
+	 */
+	bufprintf("subgraph cluster_%d {\n", cluster++);
+	bufprintf("label=\"PCM devices\";style=filled;fillcolor=lightgray;\n");
+	for_each_card_rtds(card, rtd) {
+		if (rtd->dai_link->no_pcm)
+			continue;
+
+		bufprintf("w%pK [label=\"%d: %s\"];\n", rtd,
+			  rtd->pcm->device, rtd->dai_link->name);
+	}
+	bufprintf("};\n");
+
+	/*
+	 * Print the playback/capture widgets of CPU-side DAIs, and link
+	 * them to the PCM devices. Keep a list of already printed
+	 * widgets in 'wdone', so they will be skipped later. Do not put
+	 * these widgets in a component cluster like we will do with
+	 * the other widgets later, since that just clutters the graph.
+	 */
+	for_each_card_rtds(card, rtd) {
+		for_each_rtd_cpu_dais(rtd, i, dai) {
+			if (dai->playback_widget) {
+				w = dai->playback_widget;
+				bufprintf("w%pK [label=\"%s\"];\n", w, w->name);
+				if (!rtd->dai_link->no_pcm)
+					bufprintf("w%pK -> w%pK;\n", rtd, w);
+				wdone[num_wdone] = w;
+				if (num_wdone < ARRAY_SIZE(wdone))
+					num_wdone++;
+			}
+
+			if (dai->capture_widget) {
+				w = dai->capture_widget;
+				bufprintf("w%pK [label=\"%s\"];\n", w, w->name);
+				if (!rtd->dai_link->no_pcm)
+					bufprintf("w%pK -> w%pK;\n", w, rtd);
+				wdone[num_wdone] = w;
+				if (num_wdone < ARRAY_SIZE(wdone))
+					num_wdone++;
+			}
+		}
+	}
+
+	for_each_card_dapms(card, dapm) {
+		const char *prefix = soc_dapm_prefix(dapm);
+
+		if (dapm != &card->dapm) {
+			bufprintf("subgraph cluster_%d {\n", cluster++);
+			if (prefix && dapm->component)
+				bufprintf("label=\"%s (%s)\";\n", prefix,
+					  dapm->component->name);
+			else if (dapm->component)
+				bufprintf("label=\"%s\";\n",
+					  dapm->component->name);
+		}
+
+		for_each_card_widgets(dapm->card, w) {
+			const char *name = w->name;
+			bool skip = false;
+
+			if (w->dapm != dapm)
+				continue;
+
+			if (list_empty(&w->edges[0]) && list_empty(&w->edges[1]))
+				continue;
+
+			for (i = 0; i < num_wdone; i++)
+				if (wdone[i] == w)
+					skip = true;
+			if (skip)
+				continue;
+
+			if (prefix && strlen(name) > strlen(prefix) + 1)
+				name += strlen(prefix) + 1;
+
+			bufprintf("w%pK [label=\"%s\"];\n", w, name);
+		}
+
+		if (dapm != &card->dapm)
+			bufprintf("}\n");
+	}
+
+	list_for_each_entry(p, &card->paths, list) {
+		if (p->name)
+			bufprintf("w%pK -> w%pK [label=\"%s\"];\n",
+				  p->source, p->sink, p->name);
+		else
+			bufprintf("w%pK -> w%pK;\n", p->source, p->sink);
+	}
+
+	bufprintf("}\n");
+#undef bufprintf
+
+	mutex_unlock(&card->dapm_mutex);
+
+	ret = simple_read_from_buffer(user_buf, count, ppos, buf, ret);
+
+	kfree(buf);
+	return ret;
+}
+
+static const struct file_operations dapm_graph_fops = {
+	.open = simple_open,
+	.read = dapm_graph_read_file,
+	.llseek = default_llseek,
+};
+
 void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm,
 	struct dentry *parent)
 {
@@ -2220,6 +2357,10 @@ void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm,
 
 	debugfs_create_file("bias_level", 0444, dapm->debugfs_dapm, dapm,
 			    &dapm_bias_fops);
+
+	if (dapm == &dapm->card->dapm)
+		debugfs_create_file("graph.dot", 0444, dapm->debugfs_dapm,
+				    dapm->card, &dapm_graph_fops);
 }
 
 static void dapm_debugfs_add_widget(struct snd_soc_dapm_widget *w)
-- 
2.33.0

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Mon, Aug 22, 2022 at 11:52:42AM +0200, Martin Povišer wrote:

> Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
> file in debugfs, placed in the card's DAPM directory.

There was a tool floating about in the past (last copy I knew about was
on Wolfson's git but they took that down) - can we not just continue to
do that?

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Mon, Aug 22, 2022 at 11:52:42AM +0200, Martin Povišer wrote:

> Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
> file in debugfs, placed in the card's DAPM directory.

There was a tool floating about in the past (last copy I knew about was
on Wolfson's git but they took that down) - can we not just continue to
do that?

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Takashi Iwai]

On Mon, 22 Aug 2022 14:27:41 +0200,
Mark Brown wrote:
> 
> On Mon, Aug 22, 2022 at 11:52:42AM +0200, Martin Povišer wrote:
> 
> > Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
> > file in debugfs, placed in the card's DAPM directory.
> 
> There was a tool floating about in the past (last copy I knew about was
> on Wolfson's git but they took that down) - can we not just continue to
> do that?

IMO such a conversion could be done in user-space gracefully.
Or is any info missing in debugfs as of now to achieve that?

If any, we may put such a tool in the standard repo (e.g. alsa-tools),
too.


Takashi

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

> On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Aug 22, 2022 at 11:52:42AM +0200, Martin Povišer wrote:
> 
>> Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
>> file in debugfs, placed in the card's DAPM directory.
> 
> There was a tool floating about in the past (last copy I knew about was
> on Wolfson's git but they took that down) - can we not just continue to
> do that?

I don’t know the tool or where would I find it. I think it’s neat
simply having a ‘graph.dot’ at hand, especially since it requires
little code. (Although sure there’s the danger of it growing.)

Martin

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

> On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Aug 22, 2022 at 11:52:42AM +0200, Martin Povišer wrote:
> 
>> Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
>> file in debugfs, placed in the card's DAPM directory.
> 
> There was a tool floating about in the past (last copy I knew about was
> on Wolfson's git but they took that down) - can we not just continue to
> do that?

I don’t know the tool or where would I find it. I think it’s neat
simply having a ‘graph.dot’ at hand, especially since it requires
little code. (Although sure there’s the danger of it growing.)

Martin

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Mon, Aug 22, 2022 at 02:34:58PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > There was a tool floating about in the past (last copy I knew about was
> > on Wolfson's git but they took that down) - can we not just continue to
> > do that?

> IMO such a conversion could be done in user-space gracefully.
> Or is any info missing in debugfs as of now to achieve that?

Yes, we should fill any blanks in the data that's present already.

> If any, we may put such a tool in the standard repo (e.g. alsa-tools),
> too.

Indeed.

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
> > On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:

> > There was a tool floating about in the past (last copy I knew about was
> > on Wolfson's git but they took that down) - can we not just continue to
> > do that?

> I don’t know the tool or where would I find it. I think it’s neat

Copying in Charles and Richard who might know about the status of the
tool Dimitris wrote.

> simply having a ‘graph.dot’ at hand, especially since it requires
> little code. (Although sure there’s the danger of it growing.)

I'm also worried about people going in and wanting other more tool
specific formats adding, if we didn't have anything at all it'd be one
thing but we do have something.

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
> > On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:

> > There was a tool floating about in the past (last copy I knew about was
> > on Wolfson's git but they took that down) - can we not just continue to
> > do that?

> I don’t know the tool or where would I find it. I think it’s neat

Copying in Charles and Richard who might know about the status of the
tool Dimitris wrote.

> simply having a ‘graph.dot’ at hand, especially since it requires
> little code. (Although sure there’s the danger of it growing.)

I'm also worried about people going in and wanting other more tool
specific formats adding, if we didn't have anything at all it'd be one
thing but we do have something.

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Pierre-Louis Bossart]

>>> Provide a DOT summary of the DAPM graph in a newly added 'graph.dot'
>>> file in debugfs, placed in the card's DAPM directory.
>>
>> There was a tool floating about in the past (last copy I knew about was
>> on Wolfson's git but they took that down) - can we not just continue to
>> do that?
> 
> I don’t know the tool or where would I find it. I think it’s neat
> simply having a ‘graph.dot’ at hand, especially since it requires
> little code. (Although sure there’s the danger of it growing.)

The Chrome folks used an 'asoc_dapm_graph' python script since 2014
according to the copyright information. IIRC it was python2 so might
need a bit of work.

https://chromium.googlesource.com/chromiumos/third_party/adhd/+/refs/heads/master/scripts/asoc_dapm_graph

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

> On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
>>> On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:
> 
>>> There was a tool floating about in the past (last copy I knew about was
>>> on Wolfson's git but they took that down) - can we not just continue to
>>> do that?
> 
>> I don’t know the tool or where would I find it. I think it’s neat
> 
> Copying in Charles and Richard who might know about the status of the
> tool Dimitris wrote.

Thanks.

>> simply having a ‘graph.dot’ at hand, especially since it requires
>> little code. (Although sure there’s the danger of it growing.)
> 
> I'm also worried about people going in and wanting other more tool
> specific formats adding, if we didn't have anything at all it'd be one
> thing but we do have something.

Sure, although I would argue DOT is by a large margin the standard
format to represent graphs in.

Best,
Martin

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Martin Povišer]

> On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> 
> On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
>>> On 22. 8. 2022, at 14:27, Mark Brown <broonie@kernel.org> wrote:
> 
>>> There was a tool floating about in the past (last copy I knew about was
>>> on Wolfson's git but they took that down) - can we not just continue to
>>> do that?
> 
>> I don’t know the tool or where would I find it. I think it’s neat
> 
> Copying in Charles and Richard who might know about the status of the
> tool Dimitris wrote.

Thanks.

>> simply having a ‘graph.dot’ at hand, especially since it requires
>> little code. (Although sure there’s the danger of it growing.)
> 
> I'm also worried about people going in and wanting other more tool
> specific formats adding, if we didn't have anything at all it'd be one
> thing but we do have something.

Sure, although I would argue DOT is by a large margin the standard
format to represent graphs in.

Best,
Martin

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Mon, Aug 22, 2022 at 03:11:48PM +0200, Martin Povišer wrote:
> > On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:

> >> simply having a ‘graph.dot’ at hand, especially since it requires
> >> little code. (Although sure there’s the danger of it growing.)

> > I'm also worried about people going in and wanting other more tool
> > specific formats adding, if we didn't have anything at all it'd be one
> > thing but we do have something.

> Sure, although I would argue DOT is by a large margin the standard
> format to represent graphs in.

Well, the debugfs stuff there is more a general tool for introspecting
the current DAPM state than it is indended to draw a pretty picture.
When I wrote it the scale of the devices I was working with was such
that I'm not usre a full graph would've been terribly useful, and
there's even larger devices since then (though also a lot of systems
like yours which do use very much smaller devices).

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Mon, Aug 22, 2022 at 03:11:48PM +0200, Martin Povišer wrote:
> > On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:

> >> simply having a ‘graph.dot’ at hand, especially since it requires
> >> little code. (Although sure there’s the danger of it growing.)

> > I'm also worried about people going in and wanting other more tool
> > specific formats adding, if we didn't have anything at all it'd be one
> > thing but we do have something.

> Sure, although I would argue DOT is by a large margin the standard
> format to represent graphs in.

Well, the debugfs stuff there is more a general tool for introspecting
the current DAPM state than it is indended to draw a pretty picture.
When I wrote it the scale of the devices I was working with was such
that I'm not usre a full graph would've been terribly useful, and
there's even larger devices since then (though also a lot of systems
like yours which do use very much smaller devices).

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Mon, Aug 22, 2022 at 03:06:03PM +0200, Pierre-Louis Bossart wrote:

> The Chrome folks used an 'asoc_dapm_graph' python script since 2014
> according to the copyright information. IIRC it was python2 so might
> need a bit of work.

> https://chromium.googlesource.com/chromiumos/third_party/adhd/+/refs/heads/master/scripts/asoc_dapm_graph

That's a different tool but also interesting - doesn't look like it's
too advanced Python wise so should be fairly easy to update for any
Python 3 incompatibilities.

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

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Charles Keepax]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Mon, Aug 22, 2022 at 05:10:41PM +0100, Mark Brown wrote:
> On Mon, Aug 22, 2022 at 03:11:48PM +0200, Martin Povišer wrote:
> > > On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
> 
> > >> simply having a ‘graph.dot’ at hand, especially since it requires
> > >> little code. (Although sure there’s the danger of it growing.)
> 
> > > I'm also worried about people going in and wanting other more tool
> > > specific formats adding, if we didn't have anything at all it'd be one
> > > thing but we do have something.
> 
> > Sure, although I would argue DOT is by a large margin the standard
> > format to represent graphs in.
> 
> Well, the debugfs stuff there is more a general tool for introspecting
> the current DAPM state than it is indended to draw a pretty picture.
> When I wrote it the scale of the devices I was working with was such
> that I'm not usre a full graph would've been terribly useful, and
> there's even larger devices since then (though also a lot of systems
> like yours which do use very much smaller devices).

I still seem to have a copy of Dimitris's tool lying around
(attached), yes apologies we don't seem to have that publicly hosted
anymore at some point it feels like we need to look at what was
lost when the older Wolfson stuff was shutdown.

Thanks,
Charles

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

#!/bin/bash
#
# Copyright 2011, 2012, 2013 Wolfson Microelectronics plc
# Author: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# A tool to generate a visual graph of the current DAPM configuration.
# Active paths are shown in green, inactive in red.
#
# This program requires `graphviz' to be installed.

if [ $# -ne 2 ]; then
	echo "usage: $(basename $0) dapm-debugfs-path out-png" 1>&2
	exit 1
fi

widgets="$1"
outpng="$2"
graphviztmp=$(mktemp)

trap "{ rm -f $graphviztmp; exit 1; }" SIGINT SIGTERM EXIT

widget_active() {
	local w="$1"
	head -1 "$w" | grep -q ': On'
	if [ "$?" -eq 0 ]; then
		echo 1
	else
		echo 0
	fi
}

echo "digraph G {" > "$graphviztmp"
echo -e "\tbgcolor = grey" >> "$graphviztmp"

cd "$widgets"
for widget in *; do
	echo -n "Parsing widget $widget..."
	while read line; do
		echo "${line}" | grep -q '^in'
		if [ ! "$?" -eq 0 ]; then
			continue
		fi
		source=$(echo "$line" | awk -F\" '{print $4}')
		active=$(widget_active "$widget")
		if [ "$active" -eq 1 ]; then
			echo -e "\t\"$source\" [color = green]" >> "$graphviztmp"
			echo -e "\t\"$widget\" [color = green]" >> "$graphviztmp"
		else
			echo -e "\t\"$source\" [color = red]" >> "$graphviztmp"
			echo -e "\t\"$widget\" [color = red]" >> "$graphviztmp"
		fi
		echo -e "\t\"$source\" -> \"$widget\"" >> "$graphviztmp"
	done < "$widget"
	echo "OK!"
done
cd - >/dev/null

echo "}" >> "$graphviztmp"

echo -n "Generating $outpng..."
dot -Kfdp -Tpng "$graphviztmp" -o "$outpng"
echo "OK!"

Re: [PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs

[Charles Keepax]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Mon, Aug 22, 2022 at 05:10:41PM +0100, Mark Brown wrote:
> On Mon, Aug 22, 2022 at 03:11:48PM +0200, Martin Povišer wrote:
> > > On 22. 8. 2022, at 15:04, Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Aug 22, 2022 at 02:38:09PM +0200, Martin Povišer wrote:
> 
> > >> simply having a ‘graph.dot’ at hand, especially since it requires
> > >> little code. (Although sure there’s the danger of it growing.)
> 
> > > I'm also worried about people going in and wanting other more tool
> > > specific formats adding, if we didn't have anything at all it'd be one
> > > thing but we do have something.
> 
> > Sure, although I would argue DOT is by a large margin the standard
> > format to represent graphs in.
> 
> Well, the debugfs stuff there is more a general tool for introspecting
> the current DAPM state than it is indended to draw a pretty picture.
> When I wrote it the scale of the devices I was working with was such
> that I'm not usre a full graph would've been terribly useful, and
> there's even larger devices since then (though also a lot of systems
> like yours which do use very much smaller devices).

I still seem to have a copy of Dimitris's tool lying around
(attached), yes apologies we don't seem to have that publicly hosted
anymore at some point it feels like we need to look at what was
lost when the older Wolfson stuff was shutdown.

Thanks,
Charles

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

#!/bin/bash
#
# Copyright 2011, 2012, 2013 Wolfson Microelectronics plc
# Author: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# A tool to generate a visual graph of the current DAPM configuration.
# Active paths are shown in green, inactive in red.
#
# This program requires `graphviz' to be installed.

if [ $# -ne 2 ]; then
	echo "usage: $(basename $0) dapm-debugfs-path out-png" 1>&2
	exit 1
fi

widgets="$1"
outpng="$2"
graphviztmp=$(mktemp)

trap "{ rm -f $graphviztmp; exit 1; }" SIGINT SIGTERM EXIT

widget_active() {
	local w="$1"
	head -1 "$w" | grep -q ': On'
	if [ "$?" -eq 0 ]; then
		echo 1
	else
		echo 0
	fi
}

echo "digraph G {" > "$graphviztmp"
echo -e "\tbgcolor = grey" >> "$graphviztmp"

cd "$widgets"
for widget in *; do
	echo -n "Parsing widget $widget..."
	while read line; do
		echo "${line}" | grep -q '^in'
		if [ ! "$?" -eq 0 ]; then
			continue
		fi
		source=$(echo "$line" | awk -F\" '{print $4}')
		active=$(widget_active "$widget")
		if [ "$active" -eq 1 ]; then
			echo -e "\t\"$source\" [color = green]" >> "$graphviztmp"
			echo -e "\t\"$widget\" [color = green]" >> "$graphviztmp"
		else
			echo -e "\t\"$source\" [color = red]" >> "$graphviztmp"
			echo -e "\t\"$widget\" [color = red]" >> "$graphviztmp"
		fi
		echo -e "\t\"$source\" -> \"$widget\"" >> "$graphviztmp"
	done < "$widget"
	echo "OK!"
done
cd - >/dev/null

echo "}" >> "$graphviztmp"

echo -n "Generating $outpng..."
dot -Kfdp -Tpng "$graphviztmp" -o "$outpng"
echo "OK!"