Re: [PATCH] ASoC: dapm - Add API calls to query valid DAPM paths.

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Jul 07, 2011 at 05:18:47PM +0100, Liam Girdwood wrote:

[Please fix your mailer to word wrap within paragraphs, I've reflowed
all your text.]

> The reason for using a separate walk here was because this code is
> taken from my old auto-router and it was to avoid the extra logic
> introduced by the auto-router. The auto-router did need to check for
> loops and always select the shortest path when > 1 path was viable
> (interesting as WM9713 has both loops and multiple paths). Let me see
> how cleanly I can merge it into the current walk.

Alternatively could we replace the current walk?  It's O(n^2) or so in
the number of widgets so it's not the greatest treasure ever.  So long
as we only have one walk and it works I'm happy.

> > It does also occur to me that perhaps what we want to do here is allow
> > widgets to find out about paths when they're being activated anyway?

> For dynamic PCM, we need to also work out which DAIs are active based
> on the graph. Hence for playback we can supply the DAC/AIF and find
> out all the connected output AIF/Speakers/Pins/etc. This is required
> at the start of open() in order that we can call the other PCM ops for
> each DAI, codec and platform.

Right, that's not really what I'm saying though - I'm saying that
widgets in general could be interested in this information.  For
example, some charge pumps can save additional power with some input
signal paths (which is currently handled but this would make that code
more general).

> >> + * snd_soc_dapm_get_connected_widgets_type - query audio path and it's widgets.
> >> + * @dapm: the dapm context.
> >> + * @stream_name: stream name.
> >> + * @list: list of active widgets for this stream.
> >> + * @stream: stream direction.
> >> + * @type: Initial widget type.
> >> + *
> >> + * Queries DAPM graph as to whether an valid audio stream path exists for
> >> + * the DAPM stream and initial widget type specified. This takes into account
> >> + * current mixer and mux kcontrol settings. Creates list of valid widgets.
> > 
> > Why would someone want to query by type?  That seems surprising.  Name
> > and/or direction yes but type seems hard to find a use for.

> We query by type so that we can qualify the root widget for a shared
> common stream name. i.e. Dynamic DSP needs to find the AIF rather than
> a DAC for stream X.

It does?  Hrm.  Perhaps it would make life simpler if we just mandated
the use of explicit AIF widgets?