[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140522173403.GL12304@sirena.org.uk>
Date: Thu, 22 May 2014 18:34:03 +0100
From: Mark Brown <broonie@...nel.org>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Tushar Behera <tushar.behera@...aro.org>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, tiwai@...e.de, perex@...ex.cz,
dianders@...omium.org, jerry.wong@...imintegrated.com
Subject: Re: [PATCH 1/2] ASoC: max98090: Add master clock handling
On Thu, May 22, 2014 at 09:51:38AM -0600, Stephen Warren wrote:
> On 05/22/2014 03:17 AM, Tushar Behera wrote:
> > + if (!IS_ERR(max98090->mclk)) {
> > + freq = clk_round_rate(max98090->mclk, freq);
> > + clk_set_rate(max98090->mclk, freq);
> > + }
> What are the intended semantics of set_sysclk()?
> sound/soc/tegra/tegra_wm98090.c assumes that set_sysclk() is a
> notification to the CODEC driver to tell it what rate the MCLK input is
> set to (the rate is set before calling set_sysclk), whereas the code
> above assumes that this function is to tell the CODEC to somehow
> configure its input clock to be a particular rate. I have a feeling the
> code above might fail on Tegra.
It's a bit of both. Since we've never had a generic clock API (and
still don't really due to everything being a shambles) it's generally
just a notification to the CODEC that it's at the specified rate,
however if the CODEC knows about its dependencies it seems sensible for
it to tell the clock API about what was asked. Ideally we want to
remove all the ASoC specific clock control and use the clock API.
The Tegra driver will presumably succeed unless someone does the
appropriate clock hookup in DT, at which point clk_set_rate() for the
rate the clock is already at really ought to succeed so things should
continue to work.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists