Re: [PATCH 07/12] arm: omap3: am35x: Set proper powerdomain states

["Mark A. Greer" <mgreer@xxxxxxxxxxxxxxx>]

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