On Monday 14 March 2005 11:30 am, Pavel Machek wrote: > On Po 14-03-05 10:59:25, David Brownell wrote: > > > > pci_choose_state() needs to return d3hot even > > > for pmsg_freeze, because that's what old code did, and I did not audit > > > all the drivers. > > > > Seems like a problem to me. Do S1/S2/S3 transitions even > > need a "freeze" transition? I thought we'd agreed they don't; > > That's not the problem. It's _a_ problem, maybe not the one you want to focus on right now. > Old code put devices into D3hot in swsusp "freeze" case. We'll need to > do the same now, slowly auditing the drivers and removing that > unneccessary D0->D3hot->D0 transition. That's true. The extra suspend/resume transition is trouble; it's not necessary for the checkpoint stage, or system poweroff. For the record, I've recently observed that all the swsusp issues start making sense to me when I start thinking of swsusp as being completely unrelated to suspend states. (S4bios aside...) And if I don't think of it that way, I keep tripping over complications where it's fighting against "real" suspend states. The thing is, swsusp in normal usage does not involve system suspend states like S1/S2/S3, or their analogues in non-ACPI embedded systems. Neither does it involve wakeup from those states ... in fact, it fights against addressing all those. If swsusp were called a system checkpoint/restore mechanism, it'd have a much clearer relationship to power management: enabling system power-off is a useful side effect, but it's not exactly the point of a checkpoint mechanism. I suspect that if it were packaged as halt-after-checkpoint, plus resume-from-checkpoint, a lot of technical issues would start shaking out better. Also maybe some political/funding ones ... checkpointing has much value for enterprise server operations. OK, that's enough of a radical perspective for the moment. I'm not sure I'll throw any more monkey wrenches today. ;) - Dave
