Re: [RFC] Common clock framework for external clock generators

[Daniel Mack <zonque@gmail.com>]

Hi Sebastian,

On 10.05.2012 03:11, Sebastian Hesselbarh wrote:
> first of all I apologize for the quite long attachment but I think
> it is useful for the following discussion.
> 
> I recently read about the newly introduced common clock framework (ccf)
> and wondered if this could be also used for external, e.g. i2c attached,
> clock generators.
> 
> Based on my current understanding of the framework I wrote such a
> driver and now I want to present it here for clarification of some
> remarks I have regarding the framework itself.

May I kindly ask what happened to this driver? Are you planning to do
another spin for submission?


Many thanks,
Daniel




> Please do not see this driver as mature but as some kind of
> proof-of-concept. I have the driver somewhat running but stumbled
> upon some issues.
> 
> First I want to give a brief overview of the intended use case of
> this driver:
> 
> It is a driver for a clock generator that is externally attached to
> a Marvell Dove (arm/mach-dove) SoC. It will provide driver configurable
> clocks that are connected to dedicated clock inputs of the SoC, e.g.
> external audio clock for i2s controller.
> 
> The basic intention I had in mind when writing this driver was to
> add it during platform init and pass a list of clock aliases and clock
> hierarchy description to allow the receiving driver, e.g. i2s, to set
> the rate of the supplied clock without poking the clock generator
> directly.
> 
> Please comment on the following aspects:
> - there is no clk_unregister which is okay for platform clocks but
> should be there since clock generators can be detached
> - the clock generator has two plls and up to 8 clocks; inside the
> clk_ops it is quite hard to find the correct struct clk_hw when
> using container_of()
> - most of clk_ops are spin-locked but i2c drivers tend to sleep
> during read or write; this causes a "BUG: scheduling while atomic"
> 
> I know that ccf is quite new but it is well suited for generic,
> i.e. platform independent, external clock generator drivers. Maybe
> I got the overall concept just wrong but maybe this RFC helps
> to straighten things up for future drivers.
> 
> Regards,
>      Sebastian
> 
> 
> 
> 
> 
>