The original WM8978 codec driver did not set the BCLK (bit clock)
divider, which can cause audio clocks to be incorrect or unstable
depending on the sample rate and word length.

This patch adds proper calculation and configuration of the BCLK
divider based on the sample rate and word width, ensuring the
codec generates the correct bit clock for all supported rates.

Signed-off-by: Brian Sune <briansune@gmail.com>
---
 sound/soc/codecs/wm8978.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c
index 8c45ba6fc4c3..2109c84f33df 100644
--- a/sound/soc/codecs/wm8978.c
+++ b/sound/soc/codecs/wm8978.c
@@ -717,6 +717,11 @@ static int wm8978_hw_params(struct snd_pcm_substream *substream,
 			    struct snd_pcm_hw_params *params,
 			    struct snd_soc_dai *dai)
 {
+	unsigned int bclk, bclkdiv = 0, min_diff = UINT_MAX;
+	unsigned int target_bclk = params_rate(params) * params_width(params) * 2;
+	/* WM8978 supports divisors */
+	static const int bclk_divs[] = {1, 2, 4, 8, 16, 32};
+
 	struct snd_soc_component *component = dai->component;
 	struct wm8978_priv *wm8978 = snd_soc_component_get_drvdata(component);
 	/* Word length mask = 0x60 */
@@ -820,6 +825,21 @@ static int wm8978_hw_params(struct snd_pcm_substream *substream,
 	/* MCLK divisor mask = 0xe0 */
 	snd_soc_component_update_bits(component, WM8978_CLOCKING, 0xe0, best << 5);
 
+	for (i = 0; i < ARRAY_SIZE(bclk_divs); i++) {
+		bclk = wm8978->f_256fs / bclk_divs[i];
+		if (abs(bclk - target_bclk) < min_diff) {
+			min_diff = abs(bclk - target_bclk);
+			bclkdiv = i;
+		}
+	}
+
+	dev_dbg(component->dev, "%s: fs=%u width=%u -> target BCLK=%u, using div #%u\n",
+		__func__, params_rate(params), params_width(params), target_bclk,
+		bclk_divs[bclkdiv]);
+
+	/* BCLKDIV divisor mask = 0x1c */
+	snd_soc_component_update_bits(component, WM8978_CLOCKING, 0x1c, bclkdiv << 2);
+
 	snd_soc_component_write(component, WM8978_AUDIO_INTERFACE, iface_ctl);
 	snd_soc_component_write(component, WM8978_ADDITIONAL_CONTROL, add_ctl);
 
-- 
2.47.1.windows.1

On Tue, Oct 07, 2025 at 07:33:05PM +0800, Brian Sune wrote:
> The original WM8978 codec driver did not set the BCLK (bit clock)
> divider, which can cause audio clocks to be incorrect or unstable
> depending on the sample rate and word length.

Please don't send new patches in reply to old patches or serieses, this
makes it harder for both people and tools to understand what is going
on - it can bury things in mailboxes and make it difficult to keep track
of what current patches are, both for the new patches and the old ones.

Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:44寫道：
>
> On Tue, Oct 07, 2025 at 07:33:05PM +0800, Brian Sune wrote:
> > The original WM8978 codec driver did not set the BCLK (bit clock)
> > divider, which can cause audio clocks to be incorrect or unstable
> > depending on the sample rate and word length.
>
> Please don't send new patches in reply to old patches or serieses, this
> makes it harder for both people and tools to understand what is going
> on - it can bury things in mailboxes and make it difficult to keep track
> of what current patches are, both for the new patches and the old ones.

Sorry for this action. But this patch is just a title fixe according
to previous comment.
Patch body is fully aligned to previous revision.

May I know what is the proper way to amend the title?

On Tue, Oct 07, 2025 at 07:48:11PM +0800, Sune Brian wrote:
> Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:44寫道：

> > Please don't send new patches in reply to old patches or serieses, this
> > makes it harder for both people and tools to understand what is going
> > on - it can bury things in mailboxes and make it difficult to keep track
> > of what current patches are, both for the new patches and the old ones.

> Sorry for this action. But this patch is just a title fixe according
> to previous comment.
> Patch body is fully aligned to previous revision.

> May I know what is the proper way to amend the title?

The title is fine, the above is about sending the patch as a reply.

Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:52寫道：
>
> On Tue, Oct 07, 2025 at 07:48:11PM +0800, Sune Brian wrote:
> > Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:44寫道：
>
> > > Please don't send new patches in reply to old patches or serieses, this
> > > makes it harder for both people and tools to understand what is going
> > > on - it can bury things in mailboxes and make it difficult to keep track
> > > of what current patches are, both for the new patches and the old ones.
>
> > Sorry for this action. But this patch is just a title fixe according
> > to previous comment.
> > Patch body is fully aligned to previous revision.
>
> > May I know what is the proper way to amend the title?
>
> The title is fine, the above is about sending the patch as a reply.

Got it, when title amended version is sent, need no reply with
previous revision ID.
Thank you

On Tue, Oct 07, 2025 at 07:56:31PM +0800, Sune Brian wrote:
> Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:52寫道：

> > > > Please don't send new patches in reply to old patches or serieses, this
> > > > makes it harder for both people and tools to understand what is going
> > > > on - it can bury things in mailboxes and make it difficult to keep track
> > > > of what current patches are, both for the new patches and the old ones.

> > The title is fine, the above is about sending the patch as a reply.

> Got it, when title amended version is sent, need no reply with
> previous revision ID.

No.  You sent the new version as a reply to the prior verison which
nearly got it binned.  You should send new versions as new threads, not
as replies to other serieses.

Understood, so in this situation.
What is the proper way to fix it?
Leave it as such or create a new thread?

Thank you

Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午8:10寫道：
>
> On Tue, Oct 07, 2025 at 07:56:31PM +0800, Sune Brian wrote:
> > Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午7:52寫道：
>
> > > > > Please don't send new patches in reply to old patches or serieses, this
> > > > > makes it harder for both people and tools to understand what is going
> > > > > on - it can bury things in mailboxes and make it difficult to keep track
> > > > > of what current patches are, both for the new patches and the old ones.
>
> > > The title is fine, the above is about sending the patch as a reply.
>
> > Got it, when title amended version is sent, need no reply with
> > previous revision ID.
>
> No.  You sent the new version as a reply to the prior verison which
> nearly got it binned.  You should send new versions as new threads, not
> as replies to other serieses.

On Tue, Oct 07, 2025 at 09:03:37PM +0800, Sune Brian wrote:
> Understood, so in this situation.
> What is the proper way to fix it?
> Leave it as such or create a new thread?

It's fine, just don't do this for any future versions you post.

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

Mark Brown <broonie@kernel.org> 於 2025年10月7日 週二 下午9:15寫道：
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.

Understood crop previous reply to the content that this is mail replying.
Will soon repatch another version on Charles comments.
Thank you