From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card
Date: Tue, 21 Dec 2010 16:29:40 +0000 [thread overview]
Message-ID: <20101221162940.GB21871@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201012210942.15878.peter.ujfalusi@nokia.com>
On Tue, Dec 21, 2010 at 09:42:15AM +0200, Peter Ujfalusi wrote:
> On Monday 20 December 2010 14:02:01 ext Mark Brown wrote:
> > I don't see anything different here with multi-component? The general
> > idea is that by default a floating output or input should be treated as
> > connected.
> As I said, it is another issue. It is just that for me it is more logical to
> treat the floating inputs/outputws as not connected. It is not that big problem,
> since from machine driver I can mark the unsused pins as nc.
The reason it's this way round is that this way we default to allowing
audio to pass through the system. Generally when people are bringing up
a new system they're much more worried about the hardware being at all
functional than power optimisation - in many systems power isn't a
concern at all. This way there's less obstacles to getting audio up,
and people can go through and optimise later if they need to.
> > > Now if you enable the bypass on codec2, it shall not bring up the codec2
> > > bias, since we do not have full route.
> > This isn't abundantly clear - there may potentially be analogue
> > interface issues if two devices which aren't connected aren't both
> > powered up and down together. Robust system design should avoid these
> > issues but I'd prefer it if software were conservative and at the very
> > least always had an option to ensure everything is powered on at once.
> If you look at things in card level, I still think that in the case I have
> described the codec2 shall not change bias level.
> If it does before the playback starts on the codec1, we might end up hearing the
> pop from codec1 powering up, since the codec2 path has been already up (with the
> speaker enabled).
Like I say if the speaker is unconditionally enabled DAPM will keep the
speaker output path up anyway so it's going to be up regardless of
anything else. If the bias management functions are enabling output
drivers they're doing something wrong anyway.
next prev parent reply other threads:[~2010-12-21 16:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-17 17:39 [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card Jarkko Nikula
2010-12-17 22:37 ` Mark Brown
2010-12-20 9:24 ` Liam Girdwood
2010-12-20 11:22 ` Peter Ujfalusi
2010-12-20 12:02 ` Mark Brown
2010-12-21 7:42 ` Peter Ujfalusi
2010-12-21 16:29 ` Mark Brown [this message]
2010-12-20 12:17 ` Jarkko Nikula
2010-12-21 7:30 ` Peter Ujfalusi
2010-12-21 8:16 ` Jarkko Nikula
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=20101221162940.GB21871@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=peter.ujfalusi@nokia.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.