[alsa-devel] [PATCH] ASoC: dapm: Add API call to query valid DAPM paths.
lrg at ti.com
Thu Mar 8 12:42:30 CET 2012
On Wed, 2012-03-07 at 19:15 +0000, Mark Brown wrote:
> On Wed, Mar 07, 2012 at 05:55:52PM +0000, Liam Girdwood wrote:
> > +struct snd_soc_dapm_widget_list;
> I might be blind but I think the hunk that actually declares the widget
> list got dropped from the header... probably in some other part of the
> series you haven't pushed out yet?
I had to double check myself to be sure and Stephen added it a while
> > + dev_vdbg(widget->dapm->dev," %c : %s -> %s -> %s\n",
> > + path->sink && path->connect ? '*' : ' ',
> > + widget->name, path->name, path->sink->name);
> > +
> This and the input user look like good candidates for a tracepoint, it's
> probably pretty useful to have them around and more accessible than vdbg
> is. It's the sort of information people often look for, and it's real
> time unlike the debugfs picture which isn't capturing stuff when DAPM is
> looking at it.
> > + dapm_reset(card);
> This function isn't in mainline, another patch series reordering thing I
It's in 6c120e19fa587710d80757a6e364961a017fb6c3
> It does also look like we need some locking somewhere along the
> line here (even if the only thing here is a big scary comment saying the
> relevant locks need to be held).
Oh yeah, this was post the mutex patches and got missed.
> > + dev_dbg(dai->dev, "%s: found %d paths\n",
> > + stream ? "capture" : "playback", paths);
> Tracepoint again? Much less clear for this one. I do think we should
> be dumping the stats we've been collecting for the neighbour walks, very
> useful if performance blows up again.
Yep, Tracepoint it is then.
More information about the Alsa-devel