[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <XaoRSEMyUlabAR8wEJITmm2lGCjwfPZg@localhost>
Date: Tue, 25 Oct 2022 00:17:25 +0100
From: Aidan MacDonald <aidanmacdonald.0x0@...il.com>
To: Mark Brown <broonie@...nel.org>
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
Mark Brown <broonie@...nel.org> writes:
> On Sat, Oct 22, 2022 at 05:27:41PM +0100, Aidan MacDonald wrote:
>
>> Some DAIs have multiple system clock sources, which can be chosen
>> using the "clk_id" argument to snd_soc_dai_set_sysclk(). Currently
>> this is hardcoded to 0 when using simple cards, but that choice is
>> not always suitable.
>
> 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 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().
Normal DT clocks don't seem capable of doing the job of .set_sysclk()
even in principle.
Regards,
Aidan
Powered by blists - more mailing lists