All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Liam Girdwood <lrg@ti.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [PATCH v3] ASoC: dapm - Add API call to query the widgets of valid DAPM paths.
Date: Tue, 26 Jul 2011 15:37:34 +0100	[thread overview]
Message-ID: <20110726143734.GG7285@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1311690414.2610.12.camel@CNA0741383>

On Tue, Jul 26, 2011 at 03:26:54PM +0100, Liam Girdwood wrote:
> On Tue, 2011-07-26 at 13:41 +0200, Mark Brown wrote:

> > OK, right.  If we want to do that then a substantial proportion of the
> > existing CODEC drivers are broken - they're routinely putting in the
> > stream name they want to match against rather than adding extra text to
> > the stream to give unique names that are never used.

> They should all be OK, the stream event performs a strstr() on each
> stream widget so will match left/right etc streams based on the DAI
> stream name. 

The case I'm worried about is the case where we've got two widgets with
identical stream names - left and right AIF both call their playback
widget stream "Playback" or whatever.

> > It does feel like this ought to be looking things up by widget rather
> > than by stream, though.  Widget names are already guaranteed unique and
> > if the users do want to look things up for a single widget only it seems
> > to make sense to ask for that widget rather than ask for a stream as
> > it's not how we're currently using streams.  It feels like if we're
> > asking for a stream we should do the same substring multi-match that we
> > do when pushing events into them.

> V2 did the substring match, although now that more complex hardware is
> appearing I wonder if we should connect DAIs to widgets with the widget
> name (rather than just relying on the substring). i.e. each DAI could
> have a list of AIF widgets (most would have 1 or 2). Both methods could
> co-exist for a while with the substring method being deprecated.

Yes, there's definitely room to improve here - one thing I'd like to see
is a system for mapping individual channels in the played audio so if
for example we're playing mono data (or stereo data on a 5.1 CODEC) then
we can figure out that lots of the channels aren't actually in use and
not power them on.

      reply	other threads:[~2011-07-26 14:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 10:15 [PATCH v3] ASoC: dapm - Add API call to query the widgets of valid DAPM paths Liam Girdwood
2011-07-25 21:16 ` Mark Brown
2011-07-26 11:16   ` Liam Girdwood
2011-07-26 11:41     ` Mark Brown
2011-07-26 14:26       ` Liam Girdwood
2011-07-26 14:37         ` Mark Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110726143734.GG7285@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.