All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Lars-Peter Clausen <lars@metafoo.de>,
	patches@opensource.wolfsonmicro.com, lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: arizona: Check clocking during	hw_params rather than startup
Date: Mon, 27 Jan 2014 11:25:26 +0000	[thread overview]
Message-ID: <20140127112526.GF11589@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20140127105508.GW11727@sirena.org.uk>

On Mon, Jan 27, 2014 at 10:55:08AM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 08:17:18AM +0100, Lars-Peter Clausen wrote:
> > On 01/24/2014 06:37 PM, Mark Brown wrote:
> 
> > > Thanks, that's about what I was going to write.  The current theory is
> > > that setting the sysclk to zero is the equivalent of a dynamic SYSCLK
> > > flag - with the extensive use of charge pumps and so on in modern
> > > devices on the fly reclocking is normally difficult to do safely so the
> > > idea is that if the machine driver is in a position to reclock it should
> > > set the clock to zero.
> 
> > It's a bit ugly though to set the clock to 0 in the startup callback of the
> > machine driver and then set it to the actual sysclk in the hw_params callback.
> 
> If something is doing this I'd expect it to set the clock to zero when
> it is idled rather than during startup() - set_bias_level() is usually a
> good place to do this, or possibly a DAPM widget supplying the clocks in
> the device if the clocks are visible in DAPM.  That's a bit nicer and
> doing it on startup runs into issues with things like bypass paths
> anyway.

Yeah I think the existing support is actually likely sufficent
looks likely this was actually an issue with the machine driver
in question, apologies for the noise.

Thanks,
Charles

      reply	other threads:[~2014-01-27 11:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-24 16:59 [PATCH] ASoC: arizona: Check clocking during hw_params rather than startup Charles Keepax
2014-01-24 17:25 ` Lars-Peter Clausen
2014-01-24 17:37   ` Mark Brown
2014-01-27  7:17     ` Lars-Peter Clausen
2014-01-27 10:55       ` Mark Brown
2014-01-27 11:25         ` Charles Keepax [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=20140127112526.GF11589@opensource.wolfsonmicro.com \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=patches@opensource.wolfsonmicro.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.