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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
