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

[Liam Girdwood <lrg@ti.com>]

On Thu, 2011-07-07 at 21:50 +0200, Mark Brown wrote:
> Funny formatting due to phone, sorry...

You are forgiven ;)

> 
> Indeed, but I'd have expected that anything that needed to do that would be able to (and want to) ask by name rather than type?
> 

I was generally thinking here. I'll keep it to the AIF atm and if there
is a good use for type it can always be added back later.

Liam

> Liam Girdwood <lrg@ti.com> wrote:
> 
> >On 07/07/11 17:38, Mark Brown wrote:
> >> On Thu, Jul 07, 2011 at 05:18:47PM +0100, Liam Girdwood wrote:
> >> 
> >>> 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).
> >
> >Ok, but I'm not stopping this sort of functionality from being added
> >later. Right now this is not a priority (for me anyway).
> >
> >> 
> >>>>> + * 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?
> >
> >But we may also want to know what was after a DAC. I'm thinking back
> >from the conference discussions where we could use this information to
> >selectively enable/disable kcontrols. However, this is not going to be
> >used at the moment either so I'll stick by the AIF widgets.
> >
> >Liam
> >
> >