Hi. On Wednesday 11 July 2007 11:23:02 Matthew Garrett wrote: > On Wed, Jul 11, 2007 at 10:53:35AM +1000, Nigel Cunningham wrote: > > On Wednesday 11 July 2007 10:45:50 Matthew Garrett wrote: > > > How are you going to shift into suspend to disk without going via > > > userspace? It's quite plausible that people will want different > > > configuration at that point (or, realistically, need a different set of > > > workarounds...) > > > > This is done after writing the image, from kernel space. We do the > > suspend-to-ram, and if/when we wake from that, we look at the lid switch > > state before removing the image. If it's still closed, the kernel code powers > > down again (this time properly) without userspace ever seeing the light of > > day. > > Yes. I'm sort of struggling to see how this is done especially reliably > - if we have separate hibernation and suspend to ram pathways, which is > executed in this scenario? Yeah, that is a bit confusing. At the moment, I'm doing the suspend to ram platform dependent preparation and cleanup in this scenario. That's definitely the right thing to do in the case where we write an image, then suspend to ram, wake and continue working without running running out of battery (writing the image is redundant in that case). Where we end up properly powering down after suspending to ram, I believe we don't run the pm_ops->finish after doing the atomic restore when resuming the image. I haven't looked at what uswsusp does (I'm just looking at Suspend2 code above), but it will have similar issues as it also has support for suspending to ram after writing an image. Regards, Nigel -- Nigel Cunningham Christian Reformed Church of Cobden 103 Curdie Street, Cobden 3266, Victoria, Australia Ph. +61 3 5595 1185 / +61 417 100 574 Communal Worship: 11 am Sunday.
Attachment:
pgpKytlxyYuYZ.pgp
Description: PGP signature
