[PATCH 2/2] clkdev: Implement managed clk_get()

[Stephen Boyd]

On 04/02/12 10:21, Russell King - ARM Linux wrote:
> On Mon, Apr 02, 2012 at 10:16:03AM -0700, Stephen Boyd wrote:
>> On 04/02/12 10:08, Russell King - ARM Linux wrote:
>>> Utter crap.  Deleting them makes the non-common clock implementations
>>> unsafe.  If a struct clk is provided by a module (and we do have some
>>> which are) then the module reference count has to be held.  That's
>>> what these hooks do.
>>>
>>> When these platforms get converted over to the common clock, and the
>>> issues surrounding dynamically registered and removed clocks are sane,
>>> these hooks have to be used by the common clock to deal with the
>>> refcounting so that common code knows when the structures can be freed.
>> I'm saying that when every platform is using the common clock code we
>> would only have one __clk_get() implementation and we should be able to
>> delete clkdev.h entirely.
> No you did not, you said quite clearly that clkdev should go away and
> be replaced by something else, because you see clkdev as just another
> "platform specific implementation" (your words).  You were definitely
> not talking about _just_ the backends for clkdev's clk_get().

Sorry. I was speaking about the future when we have one struct clk
definition. I suppose that wasn't clear because I wasn't explicit.

I do think we should improve/replace clkdev by keeping the core parts
(device name and connection name mapping) and internalizing it in the
common clock code. Your comment about a 1:N mapping between clocks and
devices sounds unfortunate.

Ideally we should be generating struct clks at runtime when clk_get() is
called. This way we can tie each caller of clk_get() to a different
instance of a struct clk that eventually all maps back to the same
struct clk_hw in the hardware layer. Right now clkdev is managing the
mapping at too high of a level and denies any such dynamic allocation
scheme.

If we did this it would help us locate bad drivers who all share some
clock in common. Finding which driver is keeping a clock on is annoying
when you have to trace each clk_enable/disable call and see who is
calling it to figure out which driver hasn't released its vote.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.