From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [linux-pm] Re: Hibernate after alarm wakes from STR
Date: Wed, 11 Jul 2007 12:09:04 +0200
Message-ID: <200707111209.05163.rjw@sisk.pl>
References: <20070330235759.GC4252@cosmic.amd.com> <20070711015948.GA30659@srcf.ucam.org> <200707111314.04221.nigel@nigel.suspend2.net>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Return-path: <linux-acpi-owner@vger.kernel.org>
Received: from ogre.sisk.pl ([217.79.144.158]:48997 "EHLO ogre.sisk.pl"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1762264AbXGKKBp (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
	Wed, 11 Jul 2007 06:01:45 -0400
In-Reply-To: <200707111314.04221.nigel@nigel.suspend2.net>
Content-Disposition: inline
Sender: linux-acpi-owner@vger.kernel.org
List-Id: linux-acpi@vger.kernel.org
To: nigel@suspend2.net
Cc: Matthew Garrett <mjg59@srcf.ucam.org>, David Brownell <david-b@pacbell.net>, linux-pm@lists.linux-foundation.org, Marcelo Tosatti <marcelo@kvack.org>, linux-acpi@vger.kernel.org, Richard Hughes <hughsient@gmail.com>, rtc-linux@googlegroups.com

Hi,

On Wednesday, 11 July 2007 05:14, Nigel Cunningham wrote:
> Hi.
> 
> On Wednesday 11 July 2007 11:59:48 Matthew Garrett wrote:
> > On Wed, Jul 11, 2007 at 11:39:37AM +1000, Nigel Cunningham wrote:
> > 
> > > 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'm not convinced this can work terribly well. It's not unlikely that 
> > hardware will need different state stored over different types of 
> > suspend. Can you separate out the saving of kernel memory and userspace 
> > memory, then resume/suspend/save the new kernel state without touching 
> > the userspace state?
> 
> Yeah, we could redo and resave the atomic copy, but it doesn't seem to be 
> necessary at the moment; it has been working reliably, regardless of which 
> combination of events occurs. If/when I come across a case where we have 
> problems, I'll give resaving the atomic copy a go.
> 
> (Thinks some more). Ah, I think we're already doing the right thing, if I'm 
> recalling the order of actions right. If I'm remembering correctly, prior to 
> the atomic copy, we do hibernation prep, then after the atomic copy, 
> hibernation cleanup. Then, if suspending to ram, we do the prep/enter/cleanup 
> after the image has finished writing. If we lose power from suspend to ram, 
> it doesn't matter because we're just doing a normal resume then, with the 
> hibernation cleanup post atomic restore machine the prep that was done prior 
> to the atomic copy.
> 
> To summarise:
> 
> Hibernate + STR + full wake.
>  Hibernation prep
>  (Atomic copy)
>  Hibernation cleanup
>  STR prep
>  STR enter
>  STR cleanup		
>  Remove hibernation image
> 
> Hibernate + STR + poweroff + hibernate resume:
> 
>  Hibernation prep
>  (Atomic copy)
>  Hibernation cleanup
>  STR prep
>  STR enter
>  <power out> or <STR wake + power off> (STR prep/enter no longer matters)
>  (Fresh boot)
>  Atomic restore
>  Hibernation cleanup (matching prep at start)
>  Remove hibernation image

Yes, I think that this is the right ordering, but for some graphics adapters
we need to do some tricks from the user space before 'STR prep' and after
'STR cleanup', which is theoretically possible with uswsusp.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth