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

[Nicolin Chen]

On Sun, Apr 08, 2018 at 09:33:52PM +0200, Marek Vasut wrote:

> >>>> 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.
> 
> Except with this configuration , the audio doesn't work without this
> patch. I'm happy to receive any feedback on why or what is the problem.

I sent a patch to you and in the maillist for review. Would
you please test it and sent a Tested-by to the patch? Thanks

> >> [...]
> >>>> 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.
> 
> OK. I wonder though, don't we have code to calculate dividers in the clk
> framework already? Why is it reinvented in here ?

Well, I wrote the code four years ago, based on a much older
downstream kernel; the code also got upstream that time too.
Even NXP's latest code doesn't seemly have some diff at this
part. I guess no one had reported this bug to them or to me
until you did yesterday...