Hi. On Wednesday 11 July 2007 02:51:03 David Brownell wrote: > 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. Yeah, the bit I consider to be ugly is opening the files from within the kernel, but it seemed to be necessary in order to provide the functionality without having to rely on userspace or do some sort of messy work to figure out how to access the lid button and so on. Re proc files, are the button files already exposed under sysfs and I just don't know? If so, I'll happily shift to using them. Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info.
Attachment:
pgp6jq26BLvvB.pgp
Description: PGP signature
