Re: [PATCH] implement pm_ops.valid for everybody

Matthew Locke
2007-03-23T01:14:20Z

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.

>
> - Dave
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm