All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	alsa-devel@alsa-project.org, ac100@lists.launchpad.net,
	Stephen Warren <swarren@nvidia.com>,
	stable@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH] ASoC: dapm: Use SND_SOC_DAPM_INIT_REG_VAL in SND_SOC_DAPM_MUX
Date: Fri, 22 Nov 2013 11:35:09 -0700	[thread overview]
Message-ID: <528FA3DD.8030507@wwwdotorg.org> (raw)
In-Reply-To: <20131122183216.GP14725@sirena.org.uk>

On 11/22/2013 11:32 AM, Mark Brown wrote:
> On Fri, Nov 22, 2013 at 10:29:18AM -0700, Stephen Warren wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>> 
>> SND_SOC_DAPM_MUX() doesn't currently initialize the .mask field.
>> This results in the mux never affecting HW, since no bits are
>> ever set or cleared. Fix SND_SOC_DAPM_MUX() to use
>> SND_SOC_DAPM_INIT_REG_VAL() to set up the reg, shift, on_val, and
>> off_val fields like almost all other SND_SOC_xxx() macros. It
>> looks like this was a "typo" in the fixed commit linked below.
> 
> Hrm.  Why has nobody else noticed this?  I've been doing plenty of 
> testing that involved changing muxes...  The patch and reasoning
> makes sense but I can't immediately see why any of the testing I've
> been doing recently would've worked without it since it all relies
> on muxes being configured to make any noise.

I think it's not the mux values/routing that matter, but the mux power
gating.

Also, if HW were to power up with muxes powered, then never changing
the power gate wouldn't have any effect (aside from increased power
consumption). In my case, the mux isn't powered by default, so I saw
an issue.

  reply	other threads:[~2013-11-22 18:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 17:29 [PATCH] ASoC: dapm: Use SND_SOC_DAPM_INIT_REG_VAL in SND_SOC_DAPM_MUX Stephen Warren
2013-11-22 18:32 ` Mark Brown
2013-11-22 18:35   ` Stephen Warren [this message]
2013-11-22 19:48     ` Mark Brown
2013-11-24 13:55 ` Mark Brown

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=528FA3DD.8030507@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=ac100@lists.launchpad.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=stable@vger.kernel.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 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.