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] [day] [month] [year] [list]
Message-ID: <e5e86330-8bc6-4742-82c7-045d7b435926@sirena.org.uk>
Date: Wed, 8 Oct 2025 18:13:53 +0100
From: Mark Brown <broonie@...nel.org>
To: Sune Brian <briansune@...il.com>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ASoC: wm8978: add missing BCLK divider setup

On Wed, Oct 08, 2025 at 10:37:03PM +0800, Sune Brian wrote:

> If this concept holds.
> Are you telling me a operatable case audio can output just quicker or
> slower on such w/o issue?

Yeah, it depends a lot on the application - if you're playing music your
quality requirements are probably going to be a lot higher than if for
example you are playing warning tones.  The warning tones probably just
need to be consistent, accuracy is more of a nice to have.

> Are you telling me the left/right channel bits  are able to load
> correctly on fixed lrclk while bclk is overclock?

Yes, for a lot of devices - the most common case where extra clocks are
an issue is when a device is faking I2S support and only paying
attention to the leading edge of the LRCLK (ie, DSP mode).  In that case
extra dead BCLK cycles between the left and right channels will break.

> If so why this patch required from first place?

Aside from the interoperability issues there's also likely to be some
very marginal power gain, and slower buses tend to be more electically
robust.

> Running bclk quick and just feed in the left/right channel data on
> 1bit delay on both channel should works on IIS.
> Just make bclk /2 or /4 from mclk always works while LRCLK just fixed
> to 44.1k 48k or any audio SR?
> Datasheet WM8978: Figure 38 I2 S Audio Interface (assuming n-bit word length)

The most common case where it might matter is the above one with fake
I2S implementations (usually switching to DSP mode works around it fine,
but some devices don't do DSP mode).

> Do LRCLK is fixed but BCLK is far faster still runs properly?

Usually, yes, so long as the BCLK isn't run so fast that it's exceeding
limits the device has or otherwise causing electrical issues.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ