Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "S.j. Wang" <shengjiu.wang@nxp.com>
To:     Charles Keepax <ckeepax@opensource.cirrus.com>
CC:     "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "perex@perex.cz" <perex@perex.cz>,
        "tiwai@suse.com" <tiwai@suse.com>,
        "kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
        "allison@lohutok.net" <allison@lohutok.net>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "info@metux.net" <info@metux.net>,
        "ckeepax@opensource.wolfsonmicro.com" 
        <ckeepax@opensource.wolfsonmicro.com>,
        "patches@opensource.cirrus.com" <patches@opensource.cirrus.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: wm8960: Remove bitclk relax condition
Thread-Topic: [PATCH] ASoC: wm8960: Remove bitclk relax condition
Thread-Index: AdcP2YkNTs9JlZUES8uQJyzzMM6bKw==
Date:   Wed, 3 Mar 2021 03:03:57 +0000
Message-ID: <VI1PR0402MB33424B6B9D35C1D280BA161AE3989@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 40893219-1307-4fda-e145-08d8ddf0fd0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 03:03:57.8844
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mFdiX3CyXtpCKryx7fXeYgLBvuMaTyvqkPC7r06wVogPhQ9MkNtxI4LSKiLpfgczNnMv6rN12l6oPb0tc2AmIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6366
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> >
> > 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 =3D 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@nxp.com>
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
>=20
> 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 y=
ou
> 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 behavio=
ur is
> correct as well.
>=20
> Probably the best solution here is to add additional contraints from the
> machine driver on which rates/bit depths/channels are supported.
>=20
Just double check the issue, the real reason is in below:

    The call sequence in wm8960_configure_clocking is

       ret =3D wm8960_configure_sysclk();
       if (ret >=3D 0)
            goto configure_clock;

       ....

       ret =3D 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