[PATCH] ASoC: dapm: Export new 'graph.dot' file in debugfs
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)
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?
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
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.
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
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.
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
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).
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
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/m...
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/m...
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.
participants (5)
-
Charles Keepax
-
Mark Brown
-
Martin Povišer
-
Pierre-Louis Bossart
-
Takashi Iwai