diff mbox

ASoC: arizona: Add 32uS delay after putting FLL into freerun

Message ID 1448546600-15596-1-git-send-email-ckeepax@opensource.wolfsonmicro.com (mailing list archive)
State New, archived
Headers show

Commit Message

Charles Keepax Nov. 26, 2015, 2:03 p.m. UTC
When switching between two clock sources using the FLL freerun to smooth
the transition we should wait 32uS after putting the FLL into freerun
before we proceed. In practice we appear to be getting enough delay from
the surrounding code, but better to make it explicit.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 sound/soc/codecs/arizona.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Comments

Mark Brown Nov. 27, 2015, 12:26 p.m. UTC | #1
On Thu, Nov 26, 2015 at 02:03:20PM +0000, Charles Keepax wrote:
> When switching between two clock sources using the FLL freerun to smooth
> the transition we should wait 32uS after putting the FLL into freerun
> before we proceed. In practice we appear to be getting enough delay from
> the surrounding code, but better to make it explicit.

You'll almost certainly get 32us from just setting up the I/O and
also...

> +++ b/sound/soc/codecs/arizona.c
> @@ -2215,6 +2215,7 @@ static int arizona_enable_fll(struct arizona_fll *fll)
>  		regmap_update_bits_async(fll->arizona->regmap, fll->base + 1,
>  					 ARIZONA_FLL1_FREERUN,
>  					 ARIZONA_FLL1_FREERUN);
> +		udelay(32);

...this won't do what you say it will - the I/O is asynchronous so what
this will do is add a delay immediately after scheduling the I/O while
the I/O is at best in progress and most likely before it is ever begun.
You'd need to make the I/O synchronous to actually introduce the delay.
Charles Keepax Nov. 27, 2015, 1:05 p.m. UTC | #2
On Fri, Nov 27, 2015 at 12:26:27PM +0000, Mark Brown wrote:
> On Thu, Nov 26, 2015 at 02:03:20PM +0000, Charles Keepax wrote:
> > When switching between two clock sources using the FLL freerun to smooth
> > the transition we should wait 32uS after putting the FLL into freerun
> > before we proceed. In practice we appear to be getting enough delay from
> > the surrounding code, but better to make it explicit.
> 
> You'll almost certainly get 32us from just setting up the I/O and
> also...
> 
> > +++ b/sound/soc/codecs/arizona.c
> > @@ -2215,6 +2215,7 @@ static int arizona_enable_fll(struct arizona_fll *fll)
> >  		regmap_update_bits_async(fll->arizona->regmap, fll->base + 1,
> >  					 ARIZONA_FLL1_FREERUN,
> >  					 ARIZONA_FLL1_FREERUN);
> > +		udelay(32);
> 
> ...this won't do what you say it will - the I/O is asynchronous so what
> this will do is add a delay immediately after scheduling the I/O while
> the I/O is at best in progress and most likely before it is ever begun.
> You'd need to make the I/O synchronous to actually introduce the delay.

Oops.. missed that, apologies I will respin.

Thanks,
Charles
diff mbox

Patch

diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index e76ecc7..8cd448c 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -2215,6 +2215,7 @@  static int arizona_enable_fll(struct arizona_fll *fll)
 		regmap_update_bits_async(fll->arizona->regmap, fll->base + 1,
 					 ARIZONA_FLL1_FREERUN,
 					 ARIZONA_FLL1_FREERUN);
+		udelay(32);
 	}
 
 	/*