On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: > > Remember that suspend takes place in several phases, the first of which > > is to freeze tasks. The phases can be controlled individually by the > > process carrying out a suspend, and there's nothing to prevent you from > > stopping after the freezer phase. Devices won't get powered down, but > > Android uses aggressive runtime power management for its devices > > anyway. > > > > If you do this then the synchronization can be carried out entirely > > from userspace, with no need for kernel modifications such as suspend > > blockers. And since Android can reach essentially the same low-power > > state from idle as from suspend, it appears that they really don't need > > any kernel changes at all. > > > > I don't think this is true. If you stop after the freezer phase you > still need all the suspend blockers that are held until user-space > consumes an event, otherwise it never gets consumed since user-space > is frozen. No. You don't need to hold any suspend blockers; you merely need to unfreeze userspace. Once it is unfrozen, it will eventually consume the wakeup event. What you _do_ need to do is to prevent userspace from getting frozen again too soon. That's the purpose of the list of "active" wakeup sources. So long as the power manager believes a source is still active, it won't freeze anything. Alan Stern -- 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
