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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux