All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@caiaq.org>
To: Mark Brown <broonie@sirena.org.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: ASoC: hook for codec control updates and clock	controls
Date: Mon, 8 Dec 2008 13:18:55 +0100	[thread overview]
Message-ID: <20081208121855.GA4063@buzzloop.caiaq.de> (raw)
In-Reply-To: <20081208094843.GA7094@sirena.org.uk>

On Mon, Dec 08, 2008 at 09:48:43AM +0000, Mark Brown wrote:
> > That makes sense. However, there is this special case I'm facing here -
> > the codec's volume settings are updated and the board driver doesn't
> > notice that, so it can't react and switch on the clock for some time.
> 
> The normal thing would be to never turn off the master clock.  This is a
> very common setup - many systems will have a dedicated crystal for the
> codec which can never be disabled.  Do you actually need to turn off the
> clock (and are you sure that the codec is happy about that)?

The codec is happy about that, yes. And switching off the clock was
planned to save some power, but the more I think about it, the more I
tend to leave the clock running all the time.

In general, this chip has two purposes: one is an analog mixer and the
other is a codec, and the clock is only needed when the DAC/ADC is in
use or (for a short period) when new mixer values are written.

> > The idea is to provide a way for codecs to signal the need for the
> > master clock (or whatever clock) to be applied externally. And it's
> > actually not important what it takes to actually do that - a generic way
> > the board support code can use would be good.
> 
> This would need to at least specify the clock that needs to be turned
> on and how many cycles it needs to be turned on for.  I'm having a hard
> time getting enthusiastic about that, it seems like too much software
> especially since we can't use the clock API for any of this due to the
> inconsistent implementations.

That's why I was thinking about a general purpose callback mechanism
like the one Jarkko suggested.

> In what circumstances does the codec need the clock?  What are the
> negative consequences of it not being enabled? 

If the clock is not enabled, changes in volume registers are not applied
to the actual mixers in hardware, e.g., the gain setting does simply not
happen.

We'll think about how much disadvantage it is to keep the clock running
all the time.

Thanks,
Daniel

  reply	other threads:[~2008-12-08 12:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-07 17:38 ASoC: hook for codec control updates and clock controls Daniel Mack
2008-12-07 19:02 ` Mark Brown
2008-12-08  0:04   ` Daniel Mack
2008-12-08  9:48     ` Mark Brown
2008-12-08 12:18       ` Daniel Mack [this message]
2008-12-08 12:40         ` Mark Brown
2008-12-08  9:49     ` Jarkko Nikula
2008-12-08 11:11       ` Mark Brown
2008-12-08 11:40         ` Jarkko Nikula
2008-12-08 11:59           ` 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=20081208121855.GA4063@buzzloop.caiaq.de \
    --to=daniel@caiaq.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@sirena.org.uk \
    /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.