linux-kernel - Re: [PATCH v5] ASoC: wm8978: add missing BCLK divider setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aObHCq6JAHbtTJZ8@opensource.cirrus.com>
Date: Wed, 8 Oct 2025 21:18:18 +0100
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Sune Brian <briansune@...il.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5] ASoC: wm8978: add missing BCLK divider setup

On Thu, Oct 09, 2025 at 02:27:19AM +0800, Sune Brian wrote:
> Charles Keepax <ckeepax@...nsource.cirrus.com> 於 2025年10月9日 週四 上午1:16寫道：
> Document had read and indeed it mentioned it will be ignored.
> I apologized on my strong words about IIS standard about extra bit clocks.
> However, it just mentioned if there are additional bit happens will be ignored.
> It never said this is a way to relay between MCLK LRCLK and BCLK.
> As such I am still don't convinced this is a proper way to reach the
> targeted S.R.
> And my stand of MCLK <-> BCLK <-> LRCLK relationship still holds strong.

Ah, I see what you are getting at. Yes if the LRCLK is generated
from the BCLK then the LRCLK would stretch/squash to always
provide enough bandwidth.

However, I believe most of the Wolfson parts from this era
generate the LRCLK from the internal SYSCLK directly. By the
looks of the datasheet on this part there is a fixed 256 divide
from SYSCLK to the LRCLK.

That said though, this part does somewhat pre-date me so I could
be wrong. If you have hardware and an oscilloscope this should
be pretty simple to verify in practice?

> No matter how you do it, it will only result in a close result but not
> match result.
> Doing faster BCLK but unnecessary just make setup/slack timing issues.
> Any specifications on how much you can overrun from first place?
> Which make zero sense and reason to do so from first place.

There are generally two reasons to run a faster than needed BCLK:

1) Because you can't generate the actual BCLK.
2) Because you are TDMing multiple devices onto the bus. ie.
   something else is using those extra bits.

> If BCLK is slow then the final S.R. is slowed this is what it is.
> Same as BCLK is fast then S.R. is fasted as it is.
> As for this patch do the current version introduce any error or bug.
> If not then I will stop the patching.
> Leave it to other to patch the approximated BCLK.

That is absolutely your choice. The patch should I think work
now, but could still use a little tidy up to remove the unneeded
code and big warning for something that isn't an issue.

Thanks,
Charles