From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Tue, 1 Jun 2010 20:32:02 -0700 Message-ID: References: <20100527222514.0a1710bf@lxorguk.ukuu.org.uk> <20100527230806.4deb6de3@lxorguk.ukuu.org.uk> <20100527220949.GB10602@srcf.ucam.org> <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> <20100527223605.GB11364@srcf.ucam.org> <20100527235546.09f3ce8a@lxorguk.ukuu.org.uk> <20100528043114.GC26177@thunk.org> <1275030704.32462.11.camel@laptop> <1275120618.27810.12699.camel@twins> <1275149418.4503.128.camel@mulgrave.site> <1275340869.2823.344.camel@mulgrave.site> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: James Bottomley , Peter Zijlstra , tytso@mit.edu, LKML , Florian Mickler , Linux PM , Linux OMAP Mailing List , felipe.balbi@nokia.com, Alan Cox List-Id: linux-omap@vger.kernel.org 2010/6/1 Thomas Gleixner : > > On Mon, 31 May 2010, Arve Hj=F8nnev=E5g wrote: > >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner wrote: >> > On Mon, 31 May 2010, James Bottomley wrote: >> >> >> >> For MSM hardware, it looks possible to unify the S and C states b= y 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 th= is >> > 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 hardwar= e 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 th= e >> 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. --=20 Arve Hj=F8nnev=E5g