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

Mark A. Greer
2012-04-12T02:19:24Z

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@animalcreek.com>

> >> 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
--