Re: [PATCH] implement pm_ops.valid for everybody

Igor Stoppa
2007-03-23T13:35:01Z

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)