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

[Marek Vasut]

On 04/08/2018 09:27 PM, Nicolin Chen wrote:
> 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.

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.

>> [...]
>>>> 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 ?

> Thanks
> 


-- 
Best regards,
Marek Vasut