On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox wrote: > > ACPI provides no guarantees about what level of hardware functionality > > remains during S3. You don't have any useful ability to determine which > > events will generate wakeups. And from a purely practical point of view, > > since the latency is in the range of seconds, you'll never have a low > > enough wakeup rate to hit it. > > So PCs with current ACPI don't get opportunistic suspend capability. It > probably won't be supported on the Commodore Amiga either - your point ? Actually, the reverse - there's no terribly good way to make PCs work with scheduler-based suspend, but there's no reason why they wouldn't work with the current opportunistic suspend implementation. > > Suspend blockers are the mechanism for the > > driver to indicate whether the wakeup event has been handled. That's > > what they're there for. The in-kernel ones don't paper over anything. > > Semantically the in kernel blockers and the in kernel expression of > device driven constraints are the same thing except that instead of > yes/no you replace the boolean with information. In some cases, not all. It may be a latency constraint (in which case pm_qos is an appropriate mechanism), but instead it may be something like "A key was pressed but never read" or "A network packet was received but not delivered". These don't fit into the pm_qos model, but it's state that you have to track. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
