Re: [linux-pm] Re: Hibernate after alarm wakes from STR

[David Brownell <david-b@pacbell.net>]

On Monday 09 July 2007, Nigel Cunningham wrote:
> Hi.
> 
> On Tuesday 10 July 2007 02:26:32 David Brownell wrote:
> > On Monday 09 July 2007, Marcelo Tosatti wrote:
> > > On Sun, Jul 08, 2007 at 07:44:03PM -0700, David Brownell wrote:
> > 
> > > > Better a /sys/power/wakeup_event (or whatever) that's more easily
> > > > found.  It could link to the device issuing the event.
> > > 
> > > As you mentioned, there might be two wakeup sources (RTC and power
> > > button for instance) or even more at the same time.
> > 
> > Actually I though I said that there would be races.  Though come
> > to think of it, one way they'd show up on a typical embedded system
> > would be to have multiple wake IRQs pending ... you couldn't tell
> > which one came first.  (The typical case would be a single event,
> > of course.)  ACPI-ish systems would do that with GPEs and the
> > magic "rtc woke" flag.
> > 
> > And then there are shared IRQ lines serving as wake sources.  There
> > could be three wake-enabled devices on that line (plus others that
> > aren't wake-enabled); the drivers returning IRQ_HANDLED should likely
> > be reported as having been wake sources, but not the ones returning
> > IRQ_NONE ...
> > 
> > ... so yes, systems might need to present multiple wake events.
> > 
> > 
> > > Do you think its fine to simply but the device separated by spaces in
> > > the wakeup_event file?
> > > 
> > > Sounds fine by me, but what about the one-value-per-file sysfs rule?
> > 
> > Better to have that node be a directory of links then, rather than
> > a single link.
> > 
> > Note that I'm just throwing ideas out there.  I suspect that
> > in the general case it may not be easy to map from wake event
> > to device, without infrastructure that's now missing.
> 
> FWIW, I've recently added code to Suspend2 to allow it to (optionally) set the 
> RTC wake alarm when it's finished writing the image and check the lid switch 
> when waking, entering a different sleep state if the lid switch is still 
> closed. It achieves this by letting the user set the name of an rtc alarm to 
> use (the 'rtc0' in /sys/class/rtc/rtc0/*) and of a button to use (lid/LID 
> in /proc/acpi/button/lid/LID/*). It then opens the button directory's state 
> file and the rtc directory's since_epoch and wakealarm files, and uses them 
> to determine read the time since epoch and set the wakealarm and determine 
> whether the lid button is still closed.

Interesting...

> I don't really like the opening /proc and /sysfs files in this way - whatever 
> solution you come up with, could you consider exposing some way for kernel 
> code to do this more neatly?

You're supposed to be able to use /sys/... files this way!

But that's not true of /proc/... files.

- Dave