[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200907220939.33399.david-b@pacbell.net>
Date: Wed, 22 Jul 2009 09:39:32 -0700
From: David Brownell <david-b@...bell.net>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Trilok Soni <soni.trilok@...il.com>,
Pavel Machek <pavel@....cz>,
"Arve Hj?nnev?g" <arve@...roid.com>,
kernel list <linux-kernel@...r.kernel.org>,
Brian Swetland <swetland@...gle.com>,
linux-input@...r.kernel.org, Andrew Morton <akpm@...l.org>,
linux-i2c@...r.kernel.org,
Joonyoung Shim <jy0922.shim@...sung.com>,
m.szyprowski@...sung.com, t.fujak@...sung.com,
kyungmin.park@...sung.com, Peter Zijlstra <peterz@...radead.org>
Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream
On Tuesday 21 July 2009, Thomas Gleixner wrote:
> See http://lkml.org/lkml/2009/7/17/174
Interesting. The model is then to switch over to __set_irq_handler(),
or maybe set_irq_chip_and_handler(), to replace the toplevel dispatch
code for will-be-threaded IRQs which happen to be hooked up to inputs
that don't sense edges. (Agree, that seems like a goof. But hardware
designers sometimes have any choices there.)
The normal model is that boards don't get involved with that level of
logic ... all IRQs get set up once on generic code, and flow handlers
don't change. Or if they do change, it's done when changing the IRQ's
trigger mode from edge to level, or vice versa.
Can that be cleaned up a bit, so that the handle_level_oneshot_irq()
and unmask_oneshot_irq() stuff kicks in automatically when needed,
instead of requiring board-specific (or driver-specific) code to get
that stuff right?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists