[alsa-devel] [PATCH] ASoC: dapm: Add API call to query valid DAPM paths.

[Liam Girdwood]

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
back :-

fafd2176f72148e83c64a1f818ff33fceed83d08

> 
> > +		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
> expect.  

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.

Liam