Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752723Ab0FDHht (ORCPT ); Fri, 4 Jun 2010 03:37:49 -0400 Received: from mail-px0-f174.google.com ([209.85.212.174]:50965 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751952Ab0FDHhs convert rfc822-to-8bit (ORCPT ); Fri, 4 Jun 2010 03:37:48 -0400 MIME-Version: 1.0 In-Reply-To: <20100604071354.GA14451@elte.hu> References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> <20100604071354.GA14451@elte.hu> Date: Fri, 4 Jun 2010 00:37:48 -0700 Message-ID: Subject: Re: suspend blockers & Android integration From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Ingo Molnar Cc: tytso@mit.edu, Brian Swetland , Neil Brown , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Peter Zijlstra , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2474 Lines: 61 On Fri, Jun 4, 2010 at 12:13 AM, Ingo Molnar wrote: > > * Arve Hj?nnev?g wrote: > >> On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar wrote: >> ... >> > ?- Controlled auto-suspend: drivers (such as input) could on wakeup >> > ? automatically set the 'minimum wakeup latency' value of wakee tasks to a >> > ? lower value. This automatically prevents another auto-suspend in the near >> > ? future: up to the point the wakee task increases its latency (via the >> > ? scheduler syscall) again and allows suspend again. >> > >> >> How do you clear the latency value in a safe way? If another wakeup event >> happens right after your wakee task is done processing the last event and >> decides to increase its latency, auto suspend will be allowed even though >> you have an unprocessed wakeup event. Also how do you know which task will >> read the event if it is not already waiting for it? > > The easiest solution would be to not do any of that initially. (If it's ever a > concern we could subtract/add without destroying the nesting property) > > Why do you need to track input wakeups? It's rather fragile and rather Because we have keys that should always turn the screen on, but the problem is not specific to input events. If we enabled a wakeup event it usually means we need this event to always work, not just when the system is fully awake or fully suspended. > unnecessary - the idle drivers know it very well how to not go into the > deepest idle mode already today. We wont hit C8 on laptops when you are using > the desktop. > The whole point allow the use of suspend. >> > ? This means there will be no surprise suspends for a task that may take a >> > ? bit longer than usual to finish its work. [ Detail: this would only be done >> > ? for tasks that have a non-default (non-infinity) task->latency value - to >> > ? prevent the input driver from lowering latency values (and preventing >> > ? future suspends) just because some unaware apps are running and using input >> > ? drivers. ] >> >> Don't you need two inifinity values for this? > > Yes - any value above the max idle latency in the system will do. > > Thanks, > > ? ? ? ?Ingo > -- Arve Hj?nnev?g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/