From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liam Girdwood Subject: Re: [PATCH] ASoC: dapm - Add API calls to query valid DAPM paths. Date: Thu, 7 Jul 2011 21:01:07 +0100 Message-ID: <1310068867.3569.26.camel@CNA0741383> References: <1rd8leho6nsm03kw3ksf1bvk.1310068112324@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by alsa0.perex.cz (Postfix) with ESMTP id 8F476103810 for ; Mon, 11 Jul 2011 11:57:17 +0200 (CEST) In-Reply-To: <1rd8leho6nsm03kw3ksf1bvk.1310068112324@email.android.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: "alsa-devel@alsa-project.org" List-Id: alsa-devel@alsa-project.org 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 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 > > > >