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. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
