[alsa-devel] [PATCH] ASoC: fsl_esai: Clear the xPM bit when using xFP

Nicolin Chen nicoleotsuka at gmail.com
Sun Apr 8 21:27:14 CEST 2018


On Sun, Apr 08, 2018 at 01:00:07PM +0200, Marek Vasut wrote:
> On 04/08/2018 06:01 AM, Nicolin Chen wrote:
> > On Sun, Apr 08, 2018 at 04:16:39AM +0200, Marek Vasut wrote:
> > 
> >>> Could you please provide a failed
> >>> instance? It's been a while since I wrote the code. But I can tell
> >>> that PM is supposed to be called by set_sysclk() only, while FP is
> >>> used for bclk. If you clear PM when setting FP, the output of HCK
> >>> could be messed.
> >>
> >> Try feeding it the following values, The codec I use is PCM1808.
> > 
> >> [1] fsl_esai_set_dai_sysclk[227] clk_id=0 freq=24576000 dir=1
> >> [2] fsl_esai_divisor_cal[131] tx=0 ratio=2 usefp=0 fp=0
> >> [3] fsl_esai_set_bclk[322] tx=0 freq=3072000
> >> [4] fsl_esai_divisor_cal[131] tx=0 ratio=8 usefp=1 fp=8
> 
> Sorry for confusing you, clk_id in [1] should be 3 .

No worries, it doesn't change the program flow. But it makes
sense now as the input is 48MHz.

> [...]
> >> Also, I think there is another bug in the fsl_esai_divisor_cal() now
> >> that I look at it.
> > 
> >> If usefp = 0, then maxfp = 1 , then savesub = 0 and
> > 
> > I see. This actually would happen when PSR=0. And the ratio in
> > this case is <= 256 (which could be satisfied by PM only). Btw,
> > is this the reason why you got a "dirty" PM?
> > 
> > Anyway, this part is a bug. Would you like to fix it?
> 
> Clearly I'm getting a bit lost on this convoluted clock calculation.
> What is the code trying so elaborately to come up with, ideal
> configuration for each of the clock ?

It just tires to get the closet ratio to set three divisors
correspondingly. Your case should be simpler but the program
didn't cover. It's a design flaw. I will figure out the best
fix and send it soon -- will put you in Reported-by and Cc.

Thanks


More information about the Alsa-devel mailing list