On Fri, 2009-11-06 at 17:03 +0000, Matthew Garrett wrote: > Hmm. This is an interesting approach. Just to understand the usecase > better, though - my understanding is that Nokia's approach on Omap-based > devices has been to treat "suspend" as a runtime state, without actually > performing a systemwide transition. What are the constraints that make > shifting into a different hardware state more efficient for you? > In fact we are doing "retention" in idle and with the suspend path. It's specific to Android, with the global suspend and wakelock framework. When all wakelocks are released (ie screen is black, no running app), the phone goes to suspend, which freeze userspace and also suspend the device driver. This way you can choose the wakeup sources, and stay in suspend during a long time (a few hours). Without this, you have to track down all user space app that wakeup the phone, and it is hard to sleep more than a few second. The drawback is that when you want to wakeup, it takes a lot of time to unfreeze the userspace, and resume all the device driver. This is what this feature address (for low-level wakeup only). But as this patch is not Android specific, I think other platforms may use it too. Best regards, Jocelyn -- 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
