Re: [PATCH v3 02/11] OMAP3: PM: Adding voltage driver support for OMAP3

["Cousson, Benoit" <b-cousson@ti.com>]

Hi Paul,

On 9/30/2010 7:39 PM, Paul Walmsley wrote:
> Hi Benoît, Thara,
>
> On Wed, 29 Sep 2010, Kevin Hilman wrote:
>
>> Also, I'm still seeing this on boot:
>>
>>        omap_hwmod: sr1_fck: missing clockdomain for sr1_fck.
>>        omap_hwmod: sr2_fck: missing clockdomain for sr2_fck.
>>
>> We need a final solution for this problem as a prerequisite for this
>> series as well.
>
> I guess we need to figure out the appropriate clockdomains for sr1_fck and
> sr2_fck.
>
> Probably the strictly correct thing to do, vis-a-vis the hardware, is to
> place them into their own SmartReflex clockdomain/powerdomain.  But the
> PRCM doesn't export separate control registers for those, and as I
> understand it, that clockdomain/powerdomain follows the CORE
> clockdomains/powerdomain.

More or less. In theory the smartreflex power domain goes to OFF only 
when the device goes to OFF. In device RET the SR power domain is still 
active. That's why the FCLK is marked as always ON.

> Another option would be to place them into the WKUP clockdomain.  The
> source of these functional clocks in SR_ALWON_FCLK which in turn is
> generated by the PRM from SYS_CLK.  But that won't increment the CORE
> clockdomains' use-counter when the SR functional clocks are running, which
> seems desirable if the SmartReflex clockdomain/powerdomain really does
> follow CORE.
>
> So it seems to me that the best thing to do might be to place these clocks
> into the CORE_L4 clockdomain.  But perhaps you might have a different
> view?

That's should be the proper place, but after several discussion with 
Vincent then Leo, it appears that the gating of the CORE_L4 interface 
clock is triggered by a transition of the WKUP clock domain to idle...
Yeah, that's a mess... that IP does not follow any PRCM standard :-)

Originally I thought the SR_EN bits were located in the wkup register 
because Vincent was too lazy to create a new register for these 2 bits :-).
But in fact because of that hidden dependency with the wkup, it is 
almost normal to put these bits there.

Bottom-line is that we should tie them to the "wkup_clkdm".

Another important point we already discussed a little bit, but that will 
require more thoughts, is that the clock domain definition is first: 
quite fuzzy and then does not belong do the clock itself, but to the 
modules that are sharing the same interface clock.
It means that some clocks will not belong to any clock domains, and this 
is fine.
On OMAP4, that definition is clearly tied to the modules, and thus 
should be an hwmod attribute more than a clock node attribute.


Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html