Re: [PATCH] implement pm_ops.valid for everybody

Rafael J. Wysocki
2007-03-22T23:21:03Z

On Thursday, 22 March 2007 23:56, David Brownell wrote:
> 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.

I'm not talking on restrictions. I'm talking on being able to define
_anything_ more precisely then just a low-power system-wide state.

And let's start from just something, please. Like STR and "stadndby" 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?

Rafael