On Wednesday 02 June 2010, Neil Brown wrote: > On Tue, 1 Jun 2010 10:47:49 -0400 (EDT) > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: ... > So yes, there are different use cases and we should support all of them, > both "I shut the lid and my laptop really stays asleep" and "I never miss a > TXT because my phone went to sleep at a bad time". The process that > initiates the suspend has a role in choosing what can wake it up. You'd need to add some all new infrastructure for that, because right now only hardware wakeup signals are regarded as (system) wakeup events (they are either interrupts or things like PCI PMEs, possibly translated to some platform signals like GPIOs or something). I think I know how to prevent these hardware wakeup events from being lost (such that the entire suspend will be aborted if one of them happens during suspend), but for the handling of more generally defined wakeup events we'd need to provide user space with information on what wakeup events are available and how to enable and disable them, among other things. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
