On Mon, 2004-11-01 at 17:06 -0700, David Brownell wrote: > On Monday 01 November 2004 14:45, Pavel Machek wrote: > > > > > Anyway, I think what we have defined so far seem to be good enough to > > > start the actual move. The only thing I'd like you to judge is wether we > > > keep the original PM message semantics we discussed, or we move the > > > freeze semantic to a separate flag as discussed in another message so > > See below; I think the choice is really between two ways to > snapshot the system during STD: > > (a) freeze all ... then later thaw swapdev (and parents), snapshot, > and "set power state" for all > (b) "set power state" for all, then resume swapdev (and parents), > snapshot, then just "set power state" for swapdev (and parents) > > Economy of API and testing argues for (b) ... it's also only a > minor delta from STR. The main delta between that and what we > have today is that today we resume ALL (bleech!!) devices, not > just the ones essential to saving the snapshot. No. We want (c) freeze all .. snapshot ... resume all, write image, shutdown all We have to resume all before shutdown all (or suspend all) since you can't send anything but a resume to a driver that is frozen. This is for the reason I keep explaining all the time that everybody keep forgetting, that the parents beeing frozen too, the driver will have no way to talk to it's device... If we support partial tree later on, we can turn the above into (d) suspend all but swap path, freeze swap path, snapshot, resume swap path, write image, suspend swap path. > I'm uncomfortable settling on messages before we finish agreeing > on what needs to be done. (And the word "flags" always triggers > my "bad idea" radar, at least until it's sufficiently beaten down.) > > For example, I think I realized yesterday that a "freeze" (idle?) > request shares two responsibilities with a "set power state" (suspend) > message. Both need to stop the I/O queues ... and both also need to > save device state (e.g. PCI config space) so a resume() can work. > The only difference being whether device power state is changed. Yes, but saving a device state is most of the time ... a nop. In almost every cases i had to implement actual suspend/resume code, we already had all the necessary state in memory for resuming, nothing had to be "saved". > And I still think I read some folk thinking it's OK to add an > extra power cycle during the STD cycle ... that whole bit about > waking up _only_ the swap device (and ancestors) seems unsettled. > The "freeze" is in one sense maybe just a workaround for not > being able to do that. No it's not, you don't want the swap device to spin down and wake up, and freeze is needed for proper APM support too. It's also neeced for proper kexec in fact. > > > OTOH... there's preparation for shutdown, which does not fit here too > > much, and preparation for apm sleep, which does not fit, either: > > Yeah, I noticed APM sleep and ACPI sleep weren't quite the > same. If for no other reason than getting called by "apm -s" > rather than "echo standby > /sys/power/state" ... Historical reasons mostly ... and lack of a freeze state which is what APM needs. > > For shutdown, power state is not interesting, and you do not even need > > to freeze, but you'd better spin down the disks, or you loose your > > data. > > Well, that's just a case of properly quiescing the system. > It's not so much spinning down, as completely flushing the > I/O queue ... no dirty pages in Linux or disk drive caches. > > > > For apm suspend... noone knows whats really required. Theoretically, > > neither freeze nor powersaving is needed. > > APM standby is like S1, APM suspend is more like S3. It's been > ages since I've done much with APM, but I certainly know that > pci suspend calls get made even for "apm -s" (standby). Ok, but both are irrelevant to drives. On APM, the BIOS is responsible for doing the actual power state change, and the driver MUST NOT do it or BIOSes will die in flames. What we need for APM is freeze. > Quiescing the system before standby or suspend (or hibernate!) > certainly wouldn't hurt. > > - Dave > > -- Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
