linux-kernel - Re: Threaded interrupts for synaptic touchscreen in HTC dream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d6200be20907221457r4e2f6d29g57146586fd13776a@mail.gmail.com>
Date:	Wed, 22 Jul 2009 14:57:09 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	David Brownell <david-b@...bell.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	Pavel Machek <pavel@....cz>,
	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, Daniel Ribeiro <drwyrm@...il.com>
Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream

On Wed, Jul 22, 2009 at 2:04 PM, Thomas Gleixner<tglx@...utronix.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/