[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN7C2SAbzM7mbmZjnKVQ9MiFgodUWdpJG1BZhiG66RVNBs+Naw@mail.gmail.com>
Date: Thu, 9 Oct 2025 06:02:49 +0800
From: Sune Brian <briansune@...il.com>
To: Mark Brown <broonie@...nel.org>
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 v5] ASoC: wm8978: add missing BCLK divider setup
Mark Brown <broonie@...nel.org> 於 2025年10月9日 週四 上午5:44寫道:
> This is often partly a pinmuxing/routing question - if the CODEC is the
> clock provider (and perhaps you're using a CODEC PLL so the clock isn't
> visible without being output by the CODEC) then using a fast BCLK can
> either be needed due to a lack of other places to output the MCLK or
> just seem convenient to the board designer due to where the available
> pins are.
Then why this codec need to support this uncongenial design from first place?
Are this is general kernel driver trunk?
As such, this is just trying to argue and make
BCLK LRCLK noncorrelated reasonable.
If a HW designer choice to use a codec as clock generator rather than audio
bases. Why this driver got to support on that.
As such all these discussion just want to argue and make thing reasonable
w/o practical application ground.
>From all these discussions only this specific codec I cannot see reasonable
application field that you run lrclk on audio S.R. but bclk on same as mclk.
While using such configuration still generate auditable sound?
Powered by blists - more mailing lists