On Tue, Aug 03, 2010 at 10:22:55PM -0700, Arve Hjønnevåg wrote: > On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote: > > On Tue, 3 Aug 2010 17:10:15 -0700 > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > >> > >> OK, I'll bite... > >> > >> >From an Android perspective, the differences are as follows: > >> > >> 1. Deep idle states are entered only if there are no runnable > >> tasks. In contrast, opportunistic suspend can happen even when there > >> are tasks that are ready, willing, and able to run. > > > > for "system suspend", this is an absolutely valid statement. > > for "use suspend as idle state", it's not so clearly valid. > > (but this is sort of a separate problem, basically the "when do we > > freeze the tasks that we don't like for power reasons" problem, > > which in first order is independent on what kind of idle power state > > you pick, and discussed extensively elsewhere in this thread) > > > >> > >> 2. There can be a set of input events that do not bring the > >> system out of suspend, but which would bring the system out of a deep > >> idle state. For example, I believe that it was stated that > >> one of the Android-based smartphones ignores touchscreen input while > >> suspended, but pays attention to it while in deep idle states. > > > > I would argue that this is both a hardware specific issue, but also a > > policy issue. From the user point of view, screen off with idle and > > screen off with suspend aren't all that different (if my phone would > > decide to idle rather than suspend because some app blocks suspend... I > > wouldn't expect a difference in behavior when I touch the screen). > > "Screen off -> don't honor touch after a bit" is almost an independent, > > but very real, policy problem (and a forced one in suspend, I'll grant > > you that). I could even argue that the policy decision "we don't care > > about the touch screen input" is a pre-condition for entering suspend > > (or in android speak, caring for touch screen input/having the touch > > screen path active would be a suspend blocker) > > > >> > >> 3. The system comes out of a deep idle state when a timer > >> expires. In contrast, timers cannot expire while the > >> system is suspended. (This one is debatable: some people > >> argue that timers are subject to jitter, and the suspend > >> case for timers is the same as that for deep idle states, > >> but with unbounded timer jitter. Others disagree. The > >> resulting discussions have produced much heat, but little > >> light. Such is life.) > > > > I'll debate it even harder in that it's platform specific whether > > timers can get the system out of suspend or not. Clearly on the Android > > platform in question that's not the case, but for some of the Intel > > phone silicon for example, timers CAN be wake sources to get you out of > > suspend just fine. It just depend on which exact hw you talk about. > > Generally, even if the fast timers aren't wake up sources, there'll be > > some sort of alarm thing that you can pre-wake.. but yes you are right > > in saying that's rather lame. > > Either way, it's not a general property of suspend, but a property of > > suspend on the specific platform in question. > > > > I disagree. On the msm platform the low level timer that brings us out > of the low power state is the same for idle and suspend. The > difference is where which kernel api the request comes from. In idle, > the next event on the clockevents device is usually the first event. > In suspend the generic kernel timekeeping code cancels this event and > the rtc wakeup event remains. OK, good point. This choice of kernel APIs governs what I was calling "policy". Thanx, Paul _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
