[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210311164121.GH4962@sirena.org.uk>
Date: Thu, 11 Mar 2021 16:41:21 +0000
From: Mark Brown <broonie@...nel.org>
To: Michael Walle <michael@...le.cc>
Cc: Sameer Pujar <spujar@...dia.com>, alsa-devel@...a-project.org,
devicetree@...r.kernel.org, jonathanh@...dia.com,
kuninori.morimoto.gx@...esas.com, linux-kernel@...r.kernel.org,
linux-tegra@...r.kernel.org, robh@...nel.org, sharadg@...dia.com,
thierry.reding@...il.com
Subject: Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock
On Thu, Mar 11, 2021 at 04:43:20PM +0100, Michael Walle wrote:
> This could be a last resort, yes. But I'd rather see a flag which
> indicates whether the simple-audio-card should control the (first)
> clock of the codec or not. Because until now, this wasn't the case.
> And I don't know if this was an oversight or on purpose. Kuninori would
> need to comment on that. And with the "we change mclk by default", we
> break codecs with automatic sysclk generation.
It shouldn't break anything so long as the clock ends up correct via
some path. Where there's multiple options we can also try going through
them in some order, preferring the clock in the CODEC would probably
make sense from both a compatibility and quality point of view.
> > > And its fetching just the first clock, doesn't it? What happens if a
> > > codec has two clock inputs?
> > Yes, it would have been more descriptive if it were specifically
> > looking for clock "mclk". I think the original assumption was codec
> > takes one input clock (MCLK) and uses it for sysclk.
> Yeah, I've just noticed that the clk_get_rate() also only works
> for the first clock of the codec.
simple-audio-card isn't really intended to work with complex devices,
it's very much only for the simplest of use cases.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists