[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAN7C2SCwz1YwYnAD7n=t8hUxME=hihqeF8fYBtvadHVJqj1a4g@mail.gmail.com>
Date: Thu, 9 Oct 2025 00:58:20 +0800
From: Sune Brian <briansune@...il.com>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>, 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 v4] ASoC: wm8978: add missing BCLK divider setup
Richard Fitzgerald <rf@...nsource.cirrus.com> 於 2025年10月9日 週四 上午12:27寫道:
> If the _nearest_ BCLK is < 1536000 you don't have enough clock
> cycles to send all the sample bits.
If the inherent design follows the original concept of i.e. IIS.
Then the comment of not enough clock cycles to send all sample bits
won't even exist.
MCLK -> BCLK -> LRCLK.
LRCLK is always subject to BCLK by channel # and data_bits.
As for the BCLK is always subject to MCLK and oversample requirement
or codec design.
w/o MCLK rooms you cant do BCLK w/o BCLK rooms you cant do LRCLK.
LRCLK itself is always subject to the original clock frequency.
This is why there are no possible idea on not enough clock for bit load.
BCLK divided by channel * data bits itself must be hold.
Hence the result LRCLK aka final S.R. sample rate either is fasted or
slowed is what it is.
As there are no possible way to generate a incorrect divided result
when mclk is not supported by some S.R.
Then only result is S.R. is slowed or fasted based on the BCLK but not
because you are targeting a S.R. aka LRCLK.
Which result in BCLK is required to be faster.
Powered by blists - more mailing lists