On Wed, Apr 11, 2012 at 07:24:29PM -0500, Jon Hunter wrote: > > On 04/11/2012 05:40 PM, Mark A. Greer wrote: > > On Wed, Apr 11, 2012 at 03:53:30PM -0600, Paul Walmsley wrote: > >> Hi > >> > >> On Wed, 11 Apr 2012, Mark A. Greer wrote: > >> > >>> From: "Mark A. Greer" <mgreer@xxxxxxxxxxxxxxx> > >> OMAP4 PRCM actually does seem to support powerdomain INACTIVE state, > >> although it does not actually seem to represent a separate state. As I > >> understand it, it simply allows the clockdomains in the powerdomain to > >> transitioning from the ACTIVE state into the INACTIVE state. In other > >> words, it doesn't affect the powerdomain power state at all. And on OMAP4 > >> it's referred to as the ON-INACTIVE state, to clarify that it is simply a > >> variant of the ON state. I wish they had just added a separate bit for > >> this; it would have avoided some frustration... > >> > >> Anyway, my question is this: is there any point at all to defining the > >> INACTIVE state for 3517/3505, given that it apparently cannot be read > >> from, nor written to the PRCM hardware? > > > > Great question and I really don't know the answer--its too hard to know > > what's for real and what isn't in the TRM. Maybe it is best to get rid > > of INACTIVE and just leave everything ON. > > FWIW, for omap3 class device inactive is defined as ... > > "Inactive: The same as power on but all clocks are cut. Logic is not > working, because no clock is running." > > There is nothing explicit to program as far as the power domain goes. > For OMAP4 you can program the power domain to enter inactive and when > all power domains in a voltage domain are inactive the voltage domain > can enter the sleep state. Thanks Jon. Seems like getting rid of INACTIVE and staying ON is the right thing to do. Mark -- -- 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
