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.