Re: [PATCH] implement pm_ops.valid for everybody

[David Brownell <david-b@pacbell.net>]

On Thursday 22 March 2007 3:10 pm, Rafael J. Wysocki wrote:

> Well, I think the only clear distinction between the STR and "standby" is the
> necessity to go through a boot-like procedure in order to resume from the
> former.

So what's a "boot-like procedure"?   Ten instructions?  A hundred?
A thousand?  Ten thousand?  Does it take a certain amount of time?
Does it perform certain operations?  Does it involve going through
ACPI (or APM)?  If so, what about the fact that ACPI (or APM) are
involved in "standby" resumes too (on platforms using them)?

And why wouldn't a standby mode be able to do any or all of those?


> So, I'd tend to think the STR is when the CPU(s) is(are) powered 
> down and if some platforms don't support that, they just don't support the
> STR.

That seems like a counterproductive restriction.  The only reason to
adopt it is if you care so much about ACPI that you insist on using
their state definitions even on systems that will never use ACPI.

For a system that supports several power saving modes but doesn't
have the ability to turn the CPU off, what conceivable value would
there be in saying it's not OK to use the "STR" label for any of
those states?

And thus, to say that the system is only **allowed** to expose one
of those power saving modes to Linux ... and that it must always
be called "standby"?  Even if, from an external perspective, it
acts just like an STR would act?

My answer:  there is NO value to such an arbitrary restriction.


> Also, I'd like to define "standby" and STR as system-wide low power states
> which involve the freezing of processes before entering them.

That should go without saying, since "echo NAME > /sys/power/state"
does that regardless of NAME.

- Dave