On Friday 04 May 2007, Rafael J. Wysocki wrote: > On Friday, 4 May 2007 23:40, David Brownell wrote: > > On Friday 04 May 2007, Alan Stern wrote: > > > 1. Freeze tasks > > > 2. Quiesce devices and drivers > > > 3. Create snapshot > > > 4. Reactivate devices and drivers > > > 5. Save snapshot to disk > > > 6. Prepare devices for wakeup > > > 7. Power down (ACPI S4 on systems which support it) > > > > > > Leaving hibernation involves a similar sequence which I won't discuss. > > > > > > Notice that steps 1-5 above are _completely_ independent of all issues > > > concerning wakeup devices and S4 vs. S5 vs. whatever. They have to be > > > carried out for hibernation to work, no matter how the system ends up > > > getting shut down. > > > > Not exactly. Step 2 is supposed to be aware of the target state's > > capabilities, including what's wakeup-capable. ACPI uses target > > device states to choose which _SxD methods to execute, etc. (Or it > > should ... though come to think of it, I don't think I ever saw a > > hook whereby PCI could trigger that.) The hook is there, but it's not yet implemented ... patch in the works. Whoever implemented pci_choose_state() botched it up. > Still, step 4 effectively undoes at least some things we did in 2. At least > the GPEs should be enabled for normal operation so that we can save the image. And for that matter, wakeup shouldn't be limited to wake-from-sleep; runtime device PM should be able to use it. ACPI doesn't use GPEs very well at all, except maybe runtime GPEs. Step 6 needs to know the same info, so it can enable the GPEs that work from S4. > But then there's the nice picture in 9.3.3 (OS loading) that shows how OSPM > (that would be us) can verify that the hardware configuration hasn't changed. > > In fact we don't do this, because we always go to the "Load OS Images" block > and load the hibernation image from this newly loaded OS (aka the boot kernel). > > Thus our resume is always different from the "ACPI wake up from S4". Right ... "slower" being one consequence. > > ACPI is allowed to distinguish between S4 and S5 in more ways > > than just the power usage. It'd be fair for the AML to store > > state in something that retains power, and rely on that. It'd > > be better not to do things that are allowed to confuse ACPI. > > As far as I understand the specification, OSPM (ie. we) can always discard > the fact that the system has entered S4 and reinitialize everything from > scratch. At the price of making some things needlessly misbehave. Devices that can wake from D3cold will detect state being trashed if you re-init, which is at least sub-optimal if not wrong. > > Still, the point is that these systems are now > > documented to work in a particular way, and there really ought to > > be a good reason to invalidate user training and documentation. > > That's a very important point, IMO. So I just re-quoted it. ;) > > A "Soft OFF" should be S5 to conform to specs and > > documentation. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
