[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1fCfej+/WH8TI39@sirena.org.uk>
Date: Tue, 25 Oct 2022 12:03:25 +0100
From: Mark Brown <broonie@...nel.org>
To: Aidan MacDonald <aidanmacdonald.0x0@...il.com>
Cc: lgirdwood@...il.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org,
kuninori.morimoto.gx@...esas.com, perex@...ex.cz, tiwai@...e.com,
alsa-devel@...a-project.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/2] ASoC: simple-card: Support custom DAI system
clock IDs
On Tue, Oct 25, 2022 at 12:17:25AM +0100, Aidan MacDonald wrote:
> Mark Brown <broonie@...nel.org> writes:
> > We already have clock bindings, if we need to configure clocks we should
> > be using those to configure there.
> The existing clock bindings are only useful for setting rates, and
> .set_sysclk() does more than that. See my reply to Krzysztof if you
> want an explanation, check nau8821 or tas2552 codecs for an example
> of the kind of thing I'm talking about.
I thought there was stuff for muxes, but in any case if you are adding a
new binding here you could just as well add one to the clock bindings.
> I picked those codecs at random, but they are fairly representative:
> often a codec will allow the system clock to be derived from another
> I2S clock (eg. BCLK), or provided directly, or maybe generated from an
> internal PLL. In cases like that you need to configure the codec with
> .set_sysclk() to select the right input. Many card drivers need to do
> this, it's just as important as .set_fmt() or .hw_params().
There is a strong case for saying that all the clocking in CODECs might
fit into the clock API, especially given the whole DT thing.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists