On Fri, 2007-03-23 at 09:17 -0400, ext linux-pm-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote: > * Matthew Locke <matt@xxxxxxxxxxx> [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@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
