From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6) Date: Thu, 13 May 2010 14:54:05 -0700 Message-ID: <20100513215404.GN3428@atomide.com> References: <20100513194205.GC3428@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:51299 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754150Ab0EMVy1 (ORCPT ); Thu, 13 May 2010 17:54:27 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Alan Stern Cc: Matthew Garrett , Paul Walmsley , Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= , Linux-pm mailing list , Kernel development list , Tejun Heo , Oleg Nesterov , Kevin Hilman , magnus.damm@gmail.com, Theodore Ts'o , mark gross , Arjan van de Ven , Geoff Smith , Brian Swetland , "Rafael J. Wysocki" , =?utf-8?Q?Beno=C3=AEt?= Cousson , linux-omap@vger.kernel.org, Vitaly Wool , Mark Brown , Liam Girdwood * Alan Stern [100513 14:36]: > On Thu, 13 May 2010, Tony Lindgren wrote: > > > Well this is an interesting problem, and once solved will be handy > > for all kind of things. My worry is that if it's integrated in it's > > current form it will be totally out of control all over the place :( > > > > Still hoping we can come up with some clean way that avoid the patching > > all over the place part.. How about the following, can you please check > > if it would help with your example of guaranteed handling of event: > > > > 1. In the kernel, we add one more timer queue for critical timers. > > The current timer queue(s) stay as it is. > > > > 2. We allow selecting the timer based on some flag, the default > > behaviour being the current default timer queue. > > > > 3. Then we add next_timer_interupt_critical() to only query the > > critical timers along the lines of the current next_timer_interrupt(). > > > > 4. We implement a custom pm_idle that suspends the system based on > > some logic and checking if next_timer_interrupt_critical() is > > empty. If the next_timer_interrupt_critical() does not return > > anything, we assume it's OK to suspend the system. > > > > Now to me it sounds if your the input layer and userspace handle > > both grab the timers with the critical flags, it should be guaranteed > > that the events get handled before the system is suspended. > > Why do you want this to be tied to timers? Many of the events in > question are asynchronous with no specific timing relations. To me it seems that the non-timer related events can be dealt with toggling the opportunistic suspend idle flag in sysfs. That should depend on the device and use specific policy. Tony