From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: snd_soc_jack_add_gpios vs. SOC_DAPM_PIN_SWITCH
Date: Tue, 1 Feb 2011 22:27:14 +0000 [thread overview]
Message-ID: <20110201222713.GC12101@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310C8E48A@HQMAIL01.nvidia.com>
On Tue, Feb 01, 2011 at 10:59:00AM -0800, Stephen Warren wrote:
> Mark Brown wrote at Tuesday, February 01, 2011 4:34 AM:
> > Using these two together makes no sense. Either you manually control
> > the state of the output or you manage it automatically.
> I was thinking that the jack detect would be used to enable/disable widgets
> for power purposes, but with a manual override to allow SW to set up use
> cases where only the internal speakers were used, and never headphones.
> That said, if that isn't something that's ever typically done, I'm fine
> not supporting that.
It's really uncommon - generally if headphones are inserted you want to
play audio on them even if also using the speakers as when people have
headphones in they may not be able to hear the speakers. Headphones are
often pretty good earplugs too.
> > Generally a PIN_SWITCH() should only be used to offer control if none is
> > availabile within the CODEC - in the case of Harmony it wouldn't make
> > much sense as there's plenty of control in the CODEC for what gets
> > routed to the various outputs.
> IIRC, the codec controls allow selecting only what gets routed, but there
> wasn't an overall "enable/disable speakers" switch (the mute switch does
> not disable the DAPM widgets). One would have to disable all the routing
> options to disable the speaker amplifiers, which would entail remembering
> what those routing options were to restore them once the speakers were
> desired again. A manual switch avoids this.
It may make sense to have a pin switch for the speakers, it's much more
of a userspace question if you want the speakers on when the headphones
are inserted so they probably shouldn't be connected to the jack at all
(as we discussed previously). Bear in mind that in the *very* common
case where the outputs are connected to DACs only everything will get
powered off when there's no audio playing anyway.
Having looked at the WM8903 again this probably does make most sense for
the speakers.
prev parent reply other threads:[~2011-02-01 22:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 0:03 snd_soc_jack_add_gpios vs. SOC_DAPM_PIN_SWITCH Stephen Warren
2011-02-01 11:33 ` Mark Brown
2011-02-01 18:59 ` Stephen Warren
2011-02-01 22:27 ` 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=20110201222713.GC12101@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=swarren@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).