From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [PATCH 09/10] Input: Hold wake lock while event queue is not empty. Date: Fri, 13 Feb 2009 00:34:02 +0000 Message-ID: <20090213003402.GA8393@srcf.ucam.org> References: <1234316955-31304-3-git-send-email-arve@android.com> <1234316955-31304-4-git-send-email-arve@android.com> <1234316955-31304-5-git-send-email-arve@android.com> <1234316955-31304-6-git-send-email-arve@android.com> <1234316955-31304-7-git-send-email-arve@android.com> <1234316955-31304-8-git-send-email-arve@android.com> <1234316955-31304-9-git-send-email-arve@android.com> <1234316955-31304-10-git-send-email-arve@android.com> <20090212113126.GC28176@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Arve =?iso-8859-1?B?SGr4bm5lduVn?= Cc: swetland@google.com, linux-pm@lists.linux-foundation.org, u.luckas@road.de, ncunningham@crca.org.au List-Id: linux-pm@vger.kernel.org On Thu, Feb 12, 2009 at 04:27:53PM -0800, Arve Hj=F8nnev=E5g wrote: > On Thu, Feb 12, 2009 at 3:31 AM, Matthew Garrett wr= ote: > > On Tue, Feb 10, 2009 at 05:49:14PM -0800, Arve Hj=F8nnev=E5g wrote: > > > >> spin_lock(&client->buffer_lock); > >> + wake_lock_timeout(&client->wake_lock, 5 * HZ); > > > > Why the timeout version? If your input handler vanishes for more than 5 > > seconds then presumably you should be thinking about watchdoging the > > entire system. > = > The timeout allows the system to eventually suspend if someone opened > the input device and but are not reading from it. We hit this once. I > can remove the timeout, but these bugs are more visible in the stats > if we keep timeout since the expire counts will be non-zero. Mm. I'm not convinced about kernel behaviour that's designed to work = around userspace failures. The assumption that your input consumer will = act within 5 seconds is a policy decision, so should probably be left to = userspace. -- = Matthew Garrett | mjg59@srcf.ucam.org