[PATCH] ARM: omap: hwmod: warn only when clkdm is missing from both clk and hwmod

[Paul Walmsley]

On Wed, 18 Apr 2012, Cousson, Benoit wrote:

> On 4/12/2012 7:06 PM, Paul Walmsley wrote:
> > On Thu, 12 Apr 2012, Rajendra Nayak wrote:
> > 
> > > On OMAP4+, the clkdm association is moved to hwmod while on older OMAPs'
> > > its associated with a clk.
> > 
> > Sounds like this should be conditional based on the platform, then,
> > rather than weakening the warning for all platforms ?
> 
> Well, as already discussed the clockdomain information is mostly useless for
> most clock nodes because the HW is taking care of the dependencies, so
> highlighting only the ones missing in hwmod is far from enough and will avoid
> scaring people with something that is normal.

Sounds to me like the right time to make this change for OMAP4 is when the 
call to omap2_clk_disable_clkdm_control() is removed from 
clock44xx_data.c.  Hopefully that can happen as soon as someone can finish 
the analysis work that we discussed to figure out what drivers still 
aren't converted to using runtime PM, backed with omap_device & 
omap_hwmod.

And at that point, there shouldn't be any reason to test oh->_clk->clkdm 
at all on OMAP4, no?  OMAP4 should only warn if oh->clkdm_name is missing 
or can't be resolved.

> Considering that OMAP4 clock domain partition is way more complex than it was
> on OMAP2 & 3, if OMAP4 can leave without that, I doubt OMAP2 & 3 clock nodes
> will ever need it, except HW bugs, as usual.
> 
> But still, it is an exception more than the regular case.

As far as OMAP2/3 goes, when OMAP2/3 is converted to use the hwmod 
clockdomain enable sequence, that seems like a good time to drop the 
oh->_clk->clkdm test for main clocks.

I'm also wondering if we should be checking clockdomains for the optional 
clocks in _init_opt_clks()... at least on OMAP2/3, unsure about OMAP4.  
Right now we don't implement any hwmod clockdomain enable sequence for the 
optional clocks.


- Paul