[lkml]   [2012]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 2/3] clk: introduce the common clock framework
On 03/19/2012 11:56 AM, Turquette, Mike wrote:
> On Fri, Mar 16, 2012 at 8:28 PM, Saravana Kannan<> wrote:
>> On 03/15/2012 11:11 PM, Mike Turquette wrote:
>>> The common clock framework defines a common struct clk useful across
>>> most platforms as well as an implementation of the clk api that drivers
>>> can use safely for managing clocks.
>>> The net result is consolidation of many different struct clk definitions
>>> and platform-specific clock framework implementations.
>>> This patch introduces the common struct clk, struct clk_ops and an
>>> implementation of the well-known clock api in include/clk/clk.h.
>>> Platforms may define their own hardware-specific clock structure and
>>> their own clock operation callbacks, so long as it wraps an instance of
>>> struct clk_hw.
>>> See Documentation/clk.txt for more details.
>>> This patch is based on the work of Jeremy Kerr, which in turn was based
>>> on the work of Ben Herrenschmidt.
>>> Signed-off-by: Mike Turquette<>
>>> Signed-off-by: Mike Turquette<>
>>> Reviewed-by: Thomas Gleixner<>
>>> Tested-by: Andrew Lunn<>
>>> Reviewed-by: Rob Herring<rob.herring<at>>
>>> Cc: Russell King<>
>>> Cc: Jeremy Kerr<>
>>> Cc: Arnd Bergman<>
>>> Cc: Paul Walmsley<>
>>> Cc: Shawn Guo<>
>>> Cc: Sascha Hauer<>
>>> Cc: Richard Zhao<>
>>> Cc: Saravana Kannan<>
>>> Cc: Magnus Damm<>
>>> Cc: Mark Brown<>
>>> Cc: Linus Walleij<>
>>> Cc: Stephen Boyd<>
>>> Cc: Amit Kucheria<>
>>> Cc: Deepak Saxena<>
>>> Cc: Grant Likely<>
>>> ---
>> Mike,
>> Thanks for the patches! Glad to see that it's finally getting in! I sent a
>> request for a minor change as a reply to the v5 series (since it had more
>> context). Can you please take a look at that and let me know if you can send
>> out a v8 or a patch on top of this to do that?
> Hi Saravana,

Hi Mike,

> I'm not sending a v8 series since Arnd has taken in v7 for the 3.4 merge window.

Yeah, I later realized it might be better to send patches on top of v7.

> I'm formulating a reply to your v5 queries, but I'm not done looking
> at the implications of the initializer stuff. Lets keep the technical
> discussion in that thread for now.

I saw some responses from you over the weekend but not to mine. So, I
assumed you were busy with other stuff and I started working on a patch
on top of v7. I will send that out if I get around to finishing it
before you do. Hope that's alright with you.

Based on what I have done so far, to me it just looked like a search and
replace of clk->name with clk-> and similar changes for the rest
of the fields. It looks like we might be able to remove
clk_register_mux, clk_register_divider, etc if we go with this. No stong
opinion about removing those, but they seemed redundant after the
suggester refactor.

I think it would be okay to just move those init fields into clk_hw and
not bother with renaming it to clk_initializer (I would prefer, clk_info
or clk_common) if it makes the match much less invasive.


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

 \ /
  Last update: 2012-03-19 20:17    [W:0.084 / U:9.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site