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

[Rajendra Nayak]

Hi Paul,

On Friday 08 June 2012 01:10 PM, Paul Walmsley wrote:
> 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.

The more I read your response, the more I feel you have mistaken what
this patch is doing and what I am proposing.
This patch only gets rid of clkdm assocation from *non gate* clocks.
And what I am trying to say is that, this information in not
used at all (for non gate clocks) in any of the frameworks today
including clock framework.
So why should getting rid of some *unused* data have any testing
overhead?
I did propose sometime back about getting rid of *all* clk<-> clkdm
assocation for OMAP2/3 and my testing also showed some positive
results, but that was just preliminary testing and I know to be able to
do that we need to much more testing, so thats definitely not what I am
doing here.
All the gate clocks still have the clk<->clkdm association. Even if you
look at my common clk conversion series, I have retained all
clk<->clkdm associations for all gate clocks across OMAP2 and OMAP3.
For any other form of clock it was never used and hence I am getting rid
of them.

regards,
Rajendra
>
> ...
>
> 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