All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] ASoC: TWL4030: PM fix for output amplifiers
Date: Mon, 22 Mar 2010 16:19:28 +0000	[thread overview]
Message-ID: <20100322161928.GA30295@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <201003221731.14380.peter.ujfalusi@nokia.com>

On Mon, Mar 22, 2010 at 05:31:14PM +0200, Peter Ujfalusi wrote:
> On Monday 22 March 2010 17:06:03 ext Mark Brown wrote:

> > Remember, the register cache is below the controls and transparent to
> > them - if the controls haven't written a value to the chip then it will
> > not appear in the register cache so other controls will not be affected.

> Yes, but it also means, that the change will be not visible at all.
> I mean, if we did not update the reg_cache (when we should not write to the HW), 
> than that change will be gone.
> So you will only be able to change the gain on the output, when the path is 
> active?

No, the control will have to take care of only writing to the chip when
it knows it's safe to do so.

> Also, I think, if we can somehow prevent the gain change on the HW, when the 
> associated DAPM widget is not active, we would still have the problem of the 
> DAPM_MIXER. That operates from the cache, and if the cache has no 0 for the 
> gain, than that will be written to the chip.

Once again, the cache is operating below the controls transparently to
them.  If the controls haven't written a value to the chip then the
write won't have gone to the register cache either and so other parts of
the system won't be affected.  As far as the control layer is concerned
the register cache and the hardware are identical - I'm not sure why you
believe that they are separate.

Please take a look at the old PGA code I mentioned, it implements this
without any problem.  The control suppresses the write unless the
widget is powered, storing the value separately.  If the widget is
powered down then the registers aren't referred to at all when the
control is accessed.

> How I see this: we can go and introduce new controls, DAPM widgets for all type 
> just for the sake of the TWL codec. But at the end it will be still TWL 
> specific.

> I'm not saying that other codecs could not use some generic way (in a way, that 
> you have described) to make their amps muted when they are not needed.
> What I'm saying, is that I don't see a generic way which can handle the TWL 
> codec.

Could you please be more specific about what you believe is going on
with TWL4030 here?  It would really help if you could be more specific
about how you see the register cache getting updated.

  reply	other threads:[~2010-03-22 16:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 13:36 [PATCH] ASoC: TWL4030: PM fix for output amplifiers Peter Ujfalusi
2010-03-22 13:47 ` Mark Brown
2010-03-22 14:04   ` Peter Ujfalusi
2010-03-22 14:15     ` Mark Brown
2010-03-22 14:46       ` Peter Ujfalusi
2010-03-22 15:06         ` Mark Brown
2010-03-22 15:31           ` Peter Ujfalusi
2010-03-22 16:19             ` Mark Brown [this message]
2010-03-22 16:48               ` Liam Girdwood
2010-03-22 17:00                 ` Mark Brown
2010-03-23  7:05               ` Peter Ujfalusi
2010-03-23  7:59                 ` Peter Ujfalusi
2010-03-23 10:02                   ` Mark Brown
2010-03-23 12:29                     ` Peter Ujfalusi

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=20100322161928.GA30295@rakim.wolfsonmicro.main \
    --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.