On 03/19/2012 11:56 AM, Turquette, Mike wrote:

On Fri, Mar 16, 2012 at 8:28 PM, Saravana Kannan[off-list ref]  wrote:

quoted

On 03/15/2012 11:11 PM, Mike Turquette wrote:

quoted

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<redacted>
Signed-off-by: Mike Turquette<redacted>
Reviewed-by: Thomas Gleixner<redacted>
Tested-by: Andrew Lunn<andrew@lunn.ch>
Reviewed-by: Rob Herring<rob.herring<at>    calxeda.com>
Cc: Russell King<redacted>
Cc: Jeremy Kerr<redacted>
Cc: Arnd Bergman<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Shawn Guo<redacted>
Cc: Sascha Hauer<s.hauer@pengutronix.de>
Cc: Richard Zhao<redacted>
Cc: Saravana Kannan<redacted>
Cc: Magnus Damm<magnus.damm@gmail.com>
Cc: Mark Brown<redacted>
Cc: Linus Walleij<redacted>
Cc: Stephen Boyd<redacted>
Cc: Amit Kucheria<redacted>
Cc: Deepak Saxena<redacted>
Cc: Grant Likely<redacted>
---

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->hw.name 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.


Thanks,
Saravana

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