[PATCH 1/2] ASoC: nau8822: Add operation for internal PLL off and on

Hui Wang hui.wang at canonical.com
Sat Jun 4 10:23:24 CEST 2022


On 6/3/22 21:26, David Lin wrote:
> On 2022/6/3 下午 06:10, Mark Brown wrote:
>> On Fri, Jun 03, 2022 at 05:55:18PM +0800, Hui Wang wrote:
>>> On 6/2/22 18:33, Mark Brown wrote:
>>>>> Thanks for your comment. But it is weird, it doesn't work like you 
>>>>> said,
>>>>> probably need specific route setting in the machine driver level?
>>>> Is this triggering due to reprogramming the PLL for one direction
>>>> while the other is already active (eg, starting a capture during
>>>> a playba
>>> Yes, it is. With the current machine driver of fsl-asoc-card.c, if 
>>> starting
>>> a capture during a playback or starting a playback during a capture, 
>>> the
>>> codec driver will reprogram PLL parameters while PLL is on.
>> So your patch fixes that case - note however that you're probably
>> getting an audio glitch in the already active stream while doing
>> this.  I'll send a patch which should improve that shortly. BTW,
>> shouldn't the PLL power be left off if the output frequency is 0?
>
> Agree Mark's comment.
>
> By the way, when the platform's dai_link support be_hw_params_fixup 
> callback, the sample rate will be fixed to same rate, so PLL will not 
> be also reconfigured during playback and recording at the same time.
>
Agree with your comment. And the Mark's patch is a better one. After 
Mark's  patch is merged, I will revert my [1/2 PATCH] if that is not 
dropped from the Mark's tree.

And then I will update my [2/2 PATCH] as below since the error of 
"fsl-asoc-card sound-nau8822: failed to stop FLL: -22" need to be 
handled and pll_param->freq_in/freq_out need to be cleared. If 
freq_in/freq_out is not cleared, it is possible that the 
NAU8822_REG_CLOCKING can't be updated (suppose play sound by PLL -> MCLK 
-> PLL).

@@ -726,6 +726,13 @@ static int nau8822_set_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
         struct nau8822_pll *pll_param = &nau8822->pll;
         int ret, fs;

+       if (freq_in == 0 || freq_out == 0) {
+               dev_dbg(component->dev, "PLL disabled\n");
+               pll_param->freq_in = 0;
+               pll_param->freq_out = 0;
+               return 0;
+       }
+
         if (freq_in == pll_param->freq_in &&
             freq_out == pll_param->freq_out)
                 return 0;

>>> And in another case, if the snd_soc_dai_set_pll() is called in the
>>> card->set_bias_level() instead of card_hw_params(), the PLL will 
>>> keep being
>>> off since check_mclk_select_pll() always returns false.
>> That should be fixable...


More information about the Alsa-devel mailing list