Re: [PATCH] implement pm_ops.valid for everybody

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 22 March 2007 6:44 am, Scott E. Preece wrote:
> | From: "Rafael J. Wysocki" <rjw@xxxxxxx>
> | 
> | I think we can define "standby" a bit more precisely.  Something like:
> | - processes are frozen,
> | - devices are suspended,

True of all sleep states, although one wants "suspended" to
allow different levels of device functionality.  (Maybe it
can wake up, maybe its firmware is monitoring the WLAN, etc.)


> | - nonboot CPUs are down (and in low powered states, if possible),
> | - the boot CPU may or may not be in a low power state, depending on the platform,

Both seem platform-specific.  One might want the DSP to be fully
active while the control CPU is in a lowpower state, etc.


> | - "system" devices may or may not be suspended, depending on the platform,

... so this "restriction" is meaningless ...


> | - RAM is powered

I think that's assumed by all states except suspend-to-disk.  Modulo
the potential for powering off the unused banks, of course.


> | - wake up need not be BIOS-driven (main difference from "mem")
> ---
> 
> I would be tempted to say that that last bullet is the distinguishing
> characteristic - that you come back from standby by just continuing
> where you left off, but you come back from StR by something akin to
> booting.

I was going to say that even thinking about a "BIOS" is an x86-ism,
so this would be an unusably non-generic rule.  :)

SOC systems often need to drive their deepest sleep states from code
living in on-chip SRAM (maybe 16 KB).  Sometimes that's also done in
conjunction with code from an on-chip mask ROM, especially if the CPU
itself gets powered off.  That's not BIOS...


... but I guess I don't see why one would want to try to nail down
a definition of either "standby" or "STR".  The implementation will
necessarily be highly platform-specific, to the extent that almost
any rule will need to be broken somewhere.  So, why bother trying
to fit every system into the mold of APM/ACPI terminology?

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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux