On Thu, 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: > > On Thu, 27 May 2010 17:09:16 +0200 > > Peter Zijlstra <pet...@infradead.org> wrote: > > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > > > > > Opportunistic suspends are okay. > > > > > > > > The proposed userspace API is too Android-specific. > > > > > > I would argue opportunistic suspends are not ok, and therefore the > > > proposed API is utterly irrelevant. > > > > Assuming you are happy that opportunistically entering C6 and the like is > > ok via ACPI can you explain why you have a problem with opportunistic > > suspend and why it is different to a very deep sleep CPU state such as we > > have now (and which on many embedded platforms we deal with *is* sleeping > > external devices too) > > Agreed, but I understood the opportunistic suspend line from Alan Stern > to mean the echo opportunistic > /sys/power/foo thing.
Yes, that's what I meant. Why do you think it is any worse than "echo mem >/sys/power/state"? The only difference is that it will block until all in-kernel suspend blockers are disabled. Or do you also think that "echo mem >/sys/power/state" is evil and should be removed from the kernel as soon as possible? And to answer Thomas's question: The whole reason for having in-kernel suspend blockers is so that userspace can tell the system to suspend without losing wakeup events. Suppose a key is pressed just as a user program writes "mem" to /sys/power/state. The keyboard driver handles the keystroke and queues an input event. Then the system suspends and doesn't wake up until some other event occurs -- even though the keypress was an important one and it should have prevented the system from suspending. With in-kernel suspend blockers and opportunistic suspend, this scenario is prevented. That is their raison-d'etre. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
