2010/6/1 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > > On Mon, 31 May 2010, Arve Hjønnevåg wrote: > >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >> > On Mon, 31 May 2010, James Bottomley wrote: >> >> >> >> For MSM hardware, it looks possible to unify the S and C states by doing >> >> suspend to ram from idle but I'm not sure how much work that is. >> > >> > On ARM, it's not rocket science and we have in tree support for this >> > already (OMAP). I have done the same thing on a Samsung part as a >> > prove of concept two years ago and it's really easy as the hardware is >> > sane. Hint: It's designed for mobile devices :) >> > >> >> We already enter the same power state from idle and suspend on msm. In >> the absence of misbehaving apps, the difference in power consumption >> is entirely caused by periodic timers in the user-space framework >> _and_ kernel. It only takes a few timers triggering per second (I >> think 3 if they do no work) to double the average power consumption on >> the G1 if the radio is off. We originally added wakelocks because the >> hardware we had at the time had much lower power consumption in >> suspend then idle, but we still use suspend because it saves power. > > So how do you differentiate between timers which _should_ fire and > those you do not care about ? > Only alarms are allowed to fire while suspended. > We have mechanisms in place to defer timers so the wakeups are > minimized. If that's not enough we need to revisit. > Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
