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

[b-cousson@ti.com (Cousson, Benoit)]

On 4/18/2012 12:12 PM, Paul Walmsley wrote:
> On Wed, 18 Apr 2012, Cousson, Benoit wrote:
>
>> On 4/18/2012 11:40 AM, Paul Walmsley wrote:
>>
>>> 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.
>
> If that series doesn't change the model, then maybe the right fix is just
> to associate those clocks with clockdomains in clock44xx_data.c, until the
> model changes?

But the model is already different for OMAP4. Since the clkdm is 
associated with the hwmod, we already ensure that the clkdm is properly 
enabled before enabling the modulemode.
In fact the clkdm associated with the fake modulemode clk node was 
already useless for OMAP4 as soon as we had introduced the modulemode 
support in hwmod.

The only need for that today is for the few broken drivers that does use 
the clock fmwk to enable the modulemode instead of using pm_runtime.

> I looked up some of those clocks in the OMAP4430 TRM vX.  Most of them
> would be associated with either a CM clockdomain or a PRM clockdomain. The
> TRM does actually mention these two clockdomains.  Two examples (out of
> several) that mention CD_PRM and CD_CM are Figure 3-58 "CD_L4_PER
> Overview" and Figure 3-59 "CD_L3_INIT Overview".
>
> Of course, from the software's perspective, these associations would
> effectively be no-ops, as they are on OMAP2/3; but they seem to match the
> view of the hardware as described in the TRM, so at least they make sense.

Yeah, I'm just reluctant to add some more data in an already big file, 
knowing that this information will be useless, just because a couple of 
broken drivers does need that.

What we plan to do with the migration to CCF is to keep these specific 
nodes only for the broken drivers to highlight that these ones need to 
be fixed. And thus only these nodes will need the clkdm information.

Regards,
Benoit