Re: [PATCH] implement pm_ops.valid for everybody

[Igor Stoppa <igor.stoppa@nokia.com>]

On Fri, 2007-03-23 at 09:17 -0400, ext
linux-pm-bounces@lists.linux-foundation.org wrote:
> * Matthew Locke <matt@nomadgs.com> [070322 21:15]:
> > 
> > On Mar 22, 2007, at 4:55 PM, David Brownell wrote:
> > 
> > > On Thursday 22 March 2007 4:21 pm, Rafael J. Wysocki wrote:
> > >
> > >>> My answer:  there is NO value to such an arbitrary restriction.
> > >>
> > >> I'm not talking on restrictions.
> > >
> > > You most certainly did talk about them.  You said that if the
> > > hardware doesn't support a "turn CPU off" mode, then you'd
> > > define that as being incapable of implementing suspend-to-RAM.
> > > That's a restriction ... a very arbitrary one.
> > >
> > >
> > >> I'm talking on being able to define
> > >> _anything_ more precisely then just a low-power system-wide state.
> > >
> > > Me too.  And I'm trying to convey to you the results of the
> > > investigations I did on that topic.  You don't seem to like
> > > those results though ...
> > >
> > >
> > >> And let's start from just something, please.  Like STR and  
> > >> "standby" to begin
> > >> with?  At least on ACPI systems we can distinguish one from the  
> > >> other quite
> > >> clearly, so why can't we start from that and _then_ generalize?
> > >
> > > That's exactly what I did.  Looked also at APM, and several
> > > different SOC designs (AT91, OMAP1, PXA25x, SA1100, more).
> > >
> > > The generalization I came up with is what I've described.
> > > Namely, that coming up with one definition of those states
> > > that can usefully be mapped all platforms is impractical.
> > > They're just labels.  The platform implementor can choose
> > > two states to implement, but non-x86 hardware states rarely
> > > match the expectations of ACPI.
> > >
> > > So the fundamental definition needs to be in relative terms,
> > > because platform-specific differences otherwise make trouble.
> > 
> > The problem is that a 1:1 mapping between system low power state and  
> > a processor low power state is trying to be forced on every  
> > platform.  As Dave pointed out, embedded SoC's provide multiple low  
> > power states that qualify for the suspend-to-ram definition.  The  
> > only reasonable platform independent definition is that in STR memory  
> > is powered and contents preserved.  The rest is platform specific.
> > 
> > I think the right answer is that a mechanism for mapping platform  
> > specific states to the system states is needed. Platforms define  
> > their low power states and define the default for each system  
> > state .  On x86 platforms, the default just works and is probably  
> > never changed.  On embedded platforms, a policy manager can change  
> > the other low power states according to its latency and operational  
> > requirements.
> 
> Plus the states should be distributed. Trying to force the whole
> system into certain state turns things messy.
> 
> Some devices may be active while some are in retention or suspend.
> 
> Basically everything should idle itself automatically whenever
> possible based on a idle timer or some other policy, such as
> suspending a device from user space via sysfs.

The timer sound like a reasonable idea, as long as there is one timer
for each shared resource, not user.

Example:

Devices A & B share the same voltage domain.

Device A has timeout period Timeout(A)
Device B has timeout period Timeout(B)

One timer is associated to the voltage regulator/switch and will expire
at t=TIM

Every time the device d (either A or B) performs some activity, then 

TIM = max(TIM, now + Timeout(d))

When t=TIM (timer expired), then the suspend() function for each device
is called.


-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)