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@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
