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

[Cousson, Benoit]

On 4/18/2012 11:40 AM, Paul Walmsley wrote:
> On Wed, 18 Apr 2012, Cousson, Benoit wrote:
>
>> Well, the point is that we do not need this warning even for that. This
>> is something we have to ensure by reviewing carefully the code.
>
> My perspective is slightly different.
>
> Until we're sure that we don't need clock framework-based clockdomain
> control in mainline for main clocks, we shouldn't remove that warning.
> That is because clock framework-based clockdomain control works via the
> struct clk's clkdm field.  So until we switch away from that model, we
> should ensure that each clock is associated with the clockdomain that its
> clock control FSM is associated with (in OMAP3 terms).
>
> I don't have a problem with switching away from that model, or switching
> individual SoCs away from that model, as long as regressions aren't
> introduced.  But until that switch happens, it seems wise to avoid
> weakening its consistency assumptions.
>
>> If you look today, the warning is complaining about clocks that are
>> perfectly fine.
>
> Actually, mainline is only complaining about one clock:

Hehe, sure, this is because we still have a bunch of clock nodes that 
should not be there at the first place... But once you are trying to 
remove them...

> http://www.pwsan.com/omap/bootlogs/20120417/sparse_cppcheck_cleanup_3.5__0b93afd5d945a8c002f4d380a88b5d7a61c49289/4430es2panda_bootlog.txt
>
> In the current model, the right fix for that clock is to associate it with
> a CM clockdomain (see for example the 4430 TRM vX Figure 3-70 "CD_DMA
> Overview").
>
>> So keeping it will just add some noise and not necessarily highlighting
>> the real issue.
>>
>> FYI here is what we have after the clock cleanup on OMAP4 (i.e removal of modulemode clock nodes):
>>
>
> [ lots of warnings elided ]
>
>> That's a lot of noise for nothing. That's why Rajendra's patch is needed now.
>
> Sounds like the patch to alter the warnings should be associated with this
> clock cleanup series, then, since it sounds like it changes the
> clockdomain control model.

It just removes the modulemode clock nodes we were using so far. And 
since these nodes were the only ones with a clkdm on OMAP4, it is now 
complaining, because their parents clock does not have a clkdm.

> And if the model change is only affecting
> OMAP4+, then the warning change should also only apply to OMAP4+.

OK, fair enough. Let's reduce the scope of that change to OMAP4+ only.

Regards,
Benoit