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.
Attachment:
signature.asc
Description: PGP signature
