[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160226010818.GZ18327@sirena.org.uk>
Date: Fri, 26 Feb 2016 10:08:18 +0900
From: Mark Brown <broonie@...nel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: Heiko Stuebner <heiko@...ech.de>,
Mark Rutland <mark.rutland@....com>,
Oder Chiou <oder_chiou@...ltek.com>,
alsa-devel@...a-project.org, Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Liam Girdwood <lgirdwood@...il.com>,
Takashi Iwai <tiwai@...e.com>, linux-kernel@...r.kernel.org,
Sugar Zhang <sugar.zhang@...k-chips.com>,
devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Kumar Gala <galak@...eaurora.org>,
Bard Liao <bardliao@...ltek.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: rt5640: add master clock handling for
rt5640
On Wed, Feb 24, 2016 at 10:10:05AM -0600, Pierre-Louis Bossart wrote:
> On 2/23/16 9:32 PM, Mark Brown wrote:
> >That said we really do need x86 to transition to use the clock API
> >in order to integrate with external devices, where the machine driver
> >does manage clocks we want that to move to being done using the clock
> >API rather than custom APIs.
> For Baytrail audio we have a single platform clock that can be turned
> on/off and set to 19.2 MHz or 25 MHz. No other controls are available,
> no multipliers or complicated dependencies on other clocks, parents or
> children and no other users for this clock but the audio subsystem.
> I looked at the clock framework and couldn't figure out how it would simply
> map the hardware so for now the use of the MCLK is only enabled with an
> on/off or set-rate(19.2|25) custom API. I am not an expert here so if this
> clock framework becomes a requirement to upstream code I would appreciate
> any pointers to do the right thing. I really couldn't find a simple example
> with 'Put your code here' comments to use this framework.
There's a lot of helpers like -fixed, -gate and so on - this sounds like
you could probably use those helpers (there should be lots of examples
in the kernel) or just implement a simple provider (see clk-provider.h)
depending on how the control is mapped in. If it's that simple just
open coding a provider ought to do the job. Then set up the client
linkage with clkdev in some way that makes sense for your platform.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists