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...