On Thu, 2004-10-28 at 22:36 -0700, Patrick Mochel wrote: > It is a bit of a big deal. Devices go into different states depending on > whether we're suspending or shutting down. There have been problems on x86 > with devices that didn't like to go into a low-power mode before the > system turned off. (Don't recall the details, sorry). Interesting... > Not respeecting that could also mess with wake states. Oh well, we can just send a shutdown() callback when we power off... > And, real power transitions cause a spike in power consumption. Not that > it would be that much, but we would technically be wasting power and time > to actually put things into a low-power state, bring them out, then put > them back in it. No, no, read again :) freeze will not power the HW down. So we don't have multiple transition (unlike the current code). > If we have a separate power() method, we can do that independently of > freezing-snapshotting-thawing; and actually suspending the system. And, we > can re-use it for real shutdown/reboot and kexec. If you tell me how a power method can work at all once the parent devices are frozen ... That the basic reason why I keep telling this cannot work... Look again at my earlier explanations. I introduce this "freeze" message for that exact purpose of avoiding powering up/down needlessly devices when doing the suspend to disk. The entire point, as I explained in another mail, is that "freeze" means to the driver the excact same thing as "suspend" (that is stop operations and apply whatever policy is applicable to a suspended driver of that class, freeze queues for block like IDE does, drop packets for ethernet, etc... stop DMA engine too etc... so a consistent image can be saved), but _without_ actually powering anything down. So waking from this state is both fast, and without any spike. Then, we can write the suspend image, and do the real round of PM, which sort-of depends wether we'll shutdown or go to S4/5/whatever_acpi_folks_invented... Ben.
