[PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks

[Paul Walmsley]

Hi

On Thu, 7 Jun 2012, Rajendra Nayak wrote:

> Yes, I can include this as part of the common clock conversion series.
> What I was trying to say is that neither the clock framework not any
> other OMAP PM layer today makes any use of this information except for
> gate clocks. The only 2 places in the clock framework this is used is
> in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which
> are nops for non gate clocks.
> So I don;t fully understand what you mean by our current low-level PM
> design being based on this assumption that every clock belongs to a
> clockdomain.
> Did I miss anything else our PM frameworks do with the clock<->clkdm
> association? The reason I am asking is because I am doing a lot of changes
> around based on this assumption and would really like to know
> if I am missing something.

Well I guess the best thing to do is for you to do PM tests with the 
converted code and data to make sure it works.  That's what I'm worried 
most about right now for the CCF conversion; it's the most time-consuming 
part of what I do.  If the conversion works without them and everything is 
relatively clean then I probably won't have many issues with it.

...

BTW, just to continue on the clk->clkdm topic: while we might be able to 
get rid of the clk->clkdm association for OMAP4 soon, and maybe someday 
for OMAP2/3, it looks like we'll need to keep it around for at least one 
AM335x clock -- this CLKDIV32K clock.  Definitely something to keep in 
mind...


- Paul