Re: [PATCH] implement pm_ops.valid for everybody

[tony@atomide.com]

* Igor Stoppa <igor.stoppa@nokia.com> [070323 09:37]:
> 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.

What problem do you see with with device specific idle timers?

For example, what's wrong with the following:

When the device specific idle timer expires, the driver's suspend
function would get called, and the device would release it's clock
and voltage.

Then when a shared voltage domain has 0 users, that voltage domain
can be shut off. Same thing with clock domains.

Regards,

Tony