* Igor Stoppa <igor.stoppa@xxxxxxxxx> [070323 09:37]: > 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. What problem do you see with with device specific idle timers? For example, what's wrong with the following: When the device specific idle timer expires, the driver's suspend function would get called, and the device would release it's clock and voltage. Then when a shared voltage domain has 0 users, that voltage domain can be shut off. Same thing with clock domains. Regards, Tony _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
