Hi! > > > I'm not sure what hardware model you were thinking of, > > > but that approach doesn't seem like it can be "right" > > > for all hardware. The very thing that enables you to > > > enter the deepest sleep state might be that you had > > > already stopped using the 48MHz clock, PLL shut down. > > > That's a real world example from OMAP(*). > > > > > > So that issue is what I said: "don't restart". You > > > were talking about "don't stop". > > > > Well, in case of suspend-to-disk, there's no need to really enter deep > > sleep during freeze, right? > > The S4 style STD would certainly use "deep sleep". But not during freeze phase! During drivers-frozen phase, you are copying memory, you do not want your cpu sleeping. > > I'm arguing "freeze/unfreeze" can be very fast. No need to play with > > partial trees, because "freeze/unfreeze" can be fast and it is easier > > that way. > > "Can be" on some hardware, depending on how "freeze" is > implemented. What happens to devices that are already > fully shut down? Or devices that issue wakeup events > when they're unfrozen? "Can be", on all hardware. If the device is alread fully shut down, it can't generate DMA, right? So freeze is NOP. I fail to see why device would issue anything during unfreeze. > > Actually, you can't store it in device->driver_data without making > > driver_data __nosave. And that would be kind of painfull. > > Erm, care to elaborate on "__nosave"? The driver > would probably break if you didn't save its driver > data ... I suspect you're making some assumptions > about what drivers do with "freeze", ones that > should be made explicit so I can properly agree > with them (or not). Forget nosave. You simply can't tell if it was only freeze or if machine went powerdown in between based on anything in memory (without using __nosave, but you should not be using __nosave). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
