Re: [PATCH] ASoC: rt5640: add master clock handling for rt5640

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

On 2/25/16 7:08 PM, Mark Brown wrote:
> 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.

Yes there are documentation and helpers I looked into, but to the best 
of my limited knowledge not for the gate + dual-rate case. Then you jump 
to complicated configurations combining multiple base clocks that don't 
really make sense here. After one frustrating day of trying to wrap 100 
lines of code into the clock framework I gave up and kept the simple 
custom driver. There is a single client for this clock so I don't quite 
see the benefits/ROI of mapping a simple piece of hardware with a 
complex model.