Comment by margana
Odd that you would say "only Suspend to RAM", because that is far more difficult to reliably implement in terms of hardware compatibility than Suspend to Disk.
Odd that you would say "only Suspend to RAM", because that is far more difficult to reliably implement in terms of hardware compatibility than Suspend to Disk.
> powering down the peripherals
> some peripherals have to be re-initialized
AIUI, these things actually way more hard than it sounds because hardware developers live in their own world, apparently. There's been articles here on HN from mjg59's blog (who's one of the guys maintaining all this power management stuff in the Linux kernel) like this one [0] about how some hardware simply chooses to do things that make this "re-initialization" impossible to do reliably.
The main difference is that in S3 many (internal) peripherals are put to sleep but not entirely unpowered. So when the system is resumed, it's not an entirely clean slate like it would be from a fresh power up from hibernation. Unfortunately sometimes pulling down the reset line doesn't always do as thorough job as a power cycle.
AFAICT "Suspend to RAM" is basically stopping the CPU, powering down the peripherals, and keeping the DRAM unchanged and refreshed. It should be the easier option since very little state needs to be saved explicitly, the OS and apps should just receive a signal that they were interrupted, so some peripherals have to be re-initialized, and things like network and USB connections need to be re-established.
What am I missing?