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