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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
