Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754325AbZGVV5N (ORCPT ); Wed, 22 Jul 2009 17:57:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754275AbZGVV5L (ORCPT ); Wed, 22 Jul 2009 17:57:11 -0400 Received: from qw-out-2122.google.com ([74.125.92.27]:38569 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753776AbZGVV5K convert rfc822-to-8bit (ORCPT ); Wed, 22 Jul 2009 17:57:10 -0400 MIME-Version: 1.0 In-Reply-To: References: <5d5443650907151033w36008b71pe4b32bcea9489b75@mail.gmail.com> <1248269443.27058.1449.camel@twins> <200907220957.16499.david-b@pacbell.net> Date: Wed, 22 Jul 2009 14:57:09 -0700 Message-ID: Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Thomas Gleixner Cc: David Brownell , Peter Zijlstra , Mark Brown , Dmitry Torokhov , Trilok Soni , Pavel Machek , kernel list , Brian Swetland , linux-input@vger.kernel.org, Andrew Morton , linux-i2c@vger.kernel.org, Joonyoung Shim , m.szyprowski@samsung.com, t.fujak@samsung.com, kyungmin.park@samsung.com, Daniel Ribeiro 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: 2798 Lines: 69 On Wed, Jul 22, 2009 at 2:04 PM, Thomas Gleixner wrote: > On Wed, 22 Jul 2009, David Brownell wrote: >> On Wednesday 22 July 2009, Peter Zijlstra wrote: >> > Wouldn't it be better if we could express the nesting property from >> > within genirq, so that we can do things like: >> > >> > ? register_chip_nested(parent_chip, parent_irq, slave_chip); >> > >> > And let genirq set-up the needed magic to make the nesting work. >> >> I've been requesting such IRQ chaining support for some time >> now ... if the ears are now listening, that kind of direction >> should be pursued. > > Well, I was all ear back then, but the disconnect between "embedded > only needs X be happy" and my repsonsibility to keep that all working > for everyone was way larger. :) > >> > Also, how important is it that subhandler1..n run in their own thread? >> >> Completely unimportant in a practical sense. ?Undesirable, even; >> wasteful to allocate all those stack pages and keep them idle >> most of the time. >> >> There might be an argument that the design isn't technicaly done >> until that model *can* be supported. ?On the flip side, last time >> this came up there was no "customer demand" for that ... it was >> all "supplier push". >> >> >> > That is, can't we let them run from the thread that is otherwise waiting >> > for the completino anyway? >> >> That would be far preferable, yes. > > Ok, so let me summarize what we came up with so far. > > 1) handle_level_oneshot_irq is the correct answer to the problem of > those "I'm behind a slow bus" interrupt controllers. > > 2) Some mechanism to request ONESHOT from the driver level is > required. Preferrably via a flag on request_threaded_irq > > 3) a function which allows to express the nested thread irq nature of > the interrupt controller and its subdevices. > > 4) a generic serializing mechanism which is implemented via irq_chip > functions to solve the chip->mask/unmask issue for the demultiplexed > interrupts. Something like the bus_lock/bus_sync_unlock patch I posted > earlier. > > 5) a common function which allows to call the thread handler of the > subdevice interrupts in the context of the main thread which takes > care of serialization against disable/enable/request/free irq et al. > > Any more ? It would also be useful to mask an edge triggered interrupt until the thread handler has finished. The touchscreen on the G1 is connected to an edge triggered interrupt, and the touchscreen may toggle the interrupt line while reading its registers. -- 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/