| Message ID | 20220822095242.3779-1-povik+lin@cutebit.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: dapm: Export new 'graph.dot' file in debugfs | expand |
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 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: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 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.
>>> 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
> 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 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.
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 #!/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!"
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)
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(+)