From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Koul, Vinod" <vinod.koul@intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Harsha, Priya" <priya.harsha@intel.com>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: asoc SND_SOC_DAPM_AIF_IN question
Date: Fri, 24 Dec 2010 11:35:58 +0000 [thread overview]
Message-ID: <20101224113558.GB15474@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <438BB0150E931F4B9CE701519A44630104C104C6B6@bgsmsx502.gar.corp.intel.com>
On Thu, Dec 23, 2010 at 06:31:08PM +0530, Koul, Vinod wrote:
> > "Audio Supply" sounds like the main analogue bias for the CODEC - that
> > would normally be managed by set_bias_level() rather than by having it
> > supply every single widget in the CODEC map.
> Yes that would make sense. But only for Audio rail which is global codec rail.
> What do you recommend for headset and speaker rails? They would be required only for headset and speaker DAI not rest.
Supplies for them seem sensible.
> > If you have multiple links between the CPU and the CODEC with a single
> > power bit to control them all I'd suggest defining several AIF widgets,
> > each with no power management, then making the actual power controlled
> > by a supply widget. That way the power will be enabled as required but
> > you won't have tied all the data streams together in the DAPM map.
> Okay so then why should I do with several AIF widgets, wont doing that in DAI startup be a better idea?
Doing things via data rather than with explicit code tends to be lower
maintainance; there's less potential for things to go wrong and it's
usually less work to keep up to date with API changes.
prev parent reply other threads:[~2010-12-24 11:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 17:09 asoc SND_SOC_DAPM_AIF_IN question Koul, Vinod
2010-12-22 17:55 ` Mark Brown
2010-12-23 3:06 ` Koul, Vinod
2010-12-23 11:28 ` Mark Brown
2010-12-23 13:01 ` Koul, Vinod
2010-12-24 11:35 ` 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=20101224113558.GB15474@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=priya.harsha@intel.com \
--cc=vinod.koul@intel.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.