Re: Power Management Framework architectural design

["Juha Keski-Saari" <juha.keski-saari%teleca.com@localhost>]

Joerg Sonnenberger wrote:

> On Wed, Apr 09, 2008 at 10:28:49AM -0700, Matt Thomas wrote:
> > The problem is that on embedded systems, this type of power mgmt is
> > very common and should not require MD hooks.  The PM framework
> > should handle this out of the box.
> 
> Let me phrase the question differently. What should be responsible for
> enabling power / removing power when the last device in a power domain
> changes its state?
> 
> Joerg

I feel that the problem of non-conforming Power and Clock domains could
be solved by maintaining the mindset that power domains are a superset
of clock domains, and the granularity of device-level control must come
from clock control. If a device within a power domain is active, the
domain state cannot transition. But if all clocks inside the power
domain are inactive, power state transition is free.

Keeping tight control of clock states can enable near-optimal control
of power domain states as well, even though the power domain control is
"passive" in this way. Power domain states can be used to deactivate
all clocks within the domain, but individual device control does this
already and the benefit we get from power domain states is further
savings when devices within that domain are inactive.

Wouldn't this remove the particular problem in the case of OMAP2 and
enable platform dependent logic, unless there is a platform with no
clock control and driven by power domain states... but even then this
idea could be functional by motivating the power domain transitions
through its member states.

Either way, information of membership in power domains would be
mandatory, but with control of both power domains and clock domains the
combination could be functional

- Juha Keski-Saari