> >
> > Using a higher bitclk then expected doesn't always work.
> > Here is an example:
> >
> > aplay -Dhw:0,0 -d 5 -r 48000 -f S24_LE -c 2 audio48k24b2c.wav
> >
> > In this case, the required bitclk is 48000 * 24 * 2 = 2304000 but the
> > closest bitclk that can be derived is 3072000. Since the clock is
> > faster than expected, it will start to send bytes from the next
> > channel so the sound will be corrupted.
> >
> > Fixes: 82bab88910ee ("ASoC: codec: wm8960: Relax bit clock computation
> > when using PLL")
> > Fixes: 3c01b9ee2ab9 ("ASoC: codec: wm8960: Relax bit clock
> > computation")
> > Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxx>
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> > ---
>
> I think this is probably going to need a much more involved fix.
> The problem is that there are systems that depend on this behaviour, so you
> can't just flat out revert it. And to be fair the I2S specification says that bit
> clock can run at a higher rate than required for the data, so the behaviour is
> correct as well.
>
> Probably the best solution here is to add additional contraints from the
> machine driver on which rates/bit depths/channels are supported.
>
Just double check the issue, the real reason is in below:
The call sequence in wm8960_configure_clocking is
ret = wm8960_configure_sysclk();
if (ret >= 0)
goto configure_clock;
....
ret = wm8960_configure_pll();
configure_clock:
...
wm8960_configure_sysclk is called before wm8960_configure_pll, as
there is bitclk relax on both functions, so wm8960_configure_sysclk
always return success, then wm8960_configure_pll() never be called.
So bitclk relax condition should be removed in wm8960_configure_sysclk,
That wm8960_configure_pll can be called, and there is also bitclk relax
function in wm8960_configure_pll.
I will update and resend this patch.
Best regards
Wang shengjiu
