Re: Re: Hibernate after alarm wakes from STR

Nigel Cunningham
2007-07-11T01:39:37Z

[-- Attachment #1.1: Type: text/plain, Size: 1886 bytes --]

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 #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]