Re: Re: Hibernate after alarm wakes from STR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Attachment: pgp6NSVs6Oi0o.pgp
Description: PGP signature

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux