Hi!
> > Do you have a link? (I replaced it with disable_irq_nosync, if that is
> > enough...)
> >
>
> link: http://patchwork.kernel.org/patch/35515/
Thanks!
Here's my attempt at that conversion; unfortunately I'm stuck in
2.6.29 for msm stuff, so I was not even able to compile-test it :-(.
On Tue, Jul 21, 2009 at 12:59:25PM +0200, Pavel Machek wrote:
This looks like an unrelated (but useful) change:
> *
> + * http://www.synaptics.com/sites/default/files/511_99_01F.pdf
> */
This too:
> static void decode_report(struct synaptics_ts_data *ts, u8 *buf)
> {
> +/*
> + * This
Hi Mark,
On Tue, Jul 21, 2009 at 5:06 PM, Mark
Brown wrote:
> On Tue, Jul 21, 2009 at 12:59:25PM +0200, Pavel Machek wrote:
>
> This looks like an unrelated (but useful) change:
>
>> *
>> + * http://www.synaptics.com/sites/default/files/511_99_01F.pdf
>> */
>
> This too:
>
>> static void
Hi Mark,
On Tue, Jul 21, 2009 at 5:48 PM, Trilok Soni wrote:
> Hi Mark,
>
> On Tue, Jul 21, 2009 at 5:06 PM, Mark
> Brown wrote:
>> On Tue, Jul 21, 2009 at 12:59:25PM +0200, Pavel Machek wrote:
>>
>> This looks like an unrelated (but useful) change:
>>
>>> *
>>> + * http://www.synaptics.com/site
On Tue, Jul 21, 2009 at 05:48:40PM +0530, Trilok Soni wrote:
> I think threaded irqs are used in USB drivers too, I can't locate the
> patches link for that.
The only user of any kind I can see in -next is dm355evm_keys which
relies on the IRQ it uses being configured edge triggered so that it
do
On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:
> Hopefully, this thread can give all details about threaded irq discussion.
> http://lkml.org/lkml/2009/2/27/255
Yes, I'm aware of that - I read it at the time. It seemed to peter out
without any satisfactory solution, unfortunately.
On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:
>
> > Hopefully, this thread can give all details about threaded irq discussion.
>
> > http://lkml.org/lkml/2009/2/27/255
>
> Yes, I'm aware of that - I read it at the time.
On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
> On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> > On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:
> >
> > > Hopefully, this thread can give all details about threaded irq discussion.
> >
> > > http://lkml.org/lkml/2009/2/27
Em Ter, 2009-07-21 às 09:04 -0700, Dmitry Torokhov escreveu:
> On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> > - Multi-function devices like the twl4030 which have an interrupt
> >controller on them and would like to expose that interrupt controller
> >via the generic IRQ
On Tue, Jul 21, 2009 at 10:30:26PM +0200, Thomas Gleixner wrote:
> On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
>
> > On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> > > On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:
> > >
> > > > Hopefully, this thread can give all det
On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
> On Tue, Jul 21, 2009 at 10:30:26PM +0200, Thomas Gleixner wrote:
> > On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
> >
> > > On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> > > > On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrot
On Tue, Jul 21, 2009 at 10:30:26PM +0200, Thomas Gleixner wrote:
> On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
> > On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
> > > - Ordinary devices on interrupt driven or slow buses like I2C. These
> > >need something along the lines of req
On Tue, 21 Jul 2009, Mark Brown wrote:
> On Tue, Jul 21, 2009 at 10:30:26PM +0200, Thomas Gleixner wrote:
> > On Tue, 21 Jul 2009, Dmitry Torokhov wrote:
> > > On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:
>
> > > > - Ordinary devices on interrupt driven or slow buses like I2C. Th
On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:
> On Tue, 21 Jul 2009, Mark Brown wrote:
> > I'll need to have a more detailed look at that but it's not immediately
> > clear to me how a driver (or even machine) should use that code - it
> > looks more like it's intended to be cal
Mark,
On Wed, 22 Jul 2009, Mark Brown wrote:
> On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:
> > On Tue, 21 Jul 2009, Mark Brown wrote:
>
> > > I'll need to have a more detailed look at that but it's not immediately
> > > clear to me how a driver (or even machine) should use t
On Wed, 2009-07-22 at 14:58 +0200, Thomas Gleixner wrote:
> One
> thing which I definitely want to change is the thread_eoi function. We
> probably want to have it customizable for the following reason:
>
> main interrupt
> hardirq handler wakes main thread handler
>
> main thread handler
>
On Wed, Jul 22, 2009 at 02:58:24PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Mark Brown wrote:
> > On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:
> > >set_irq_handler(irq, handle_level_oneshot_irq);
> > Yeah, I know - the issue I was having was that the use of set
On Wed, 22 Jul 2009, Peter Zijlstra wrote:
> On Wed, 2009-07-22 at 14:58 +0200, Thomas Gleixner wrote:
> > Thinking further we should even provide some infrastructure for that
> > in the common code which would handle the completion and attach it to
> > the interrupts in question, so the driver aut
On Wed, Jul 22, 2009 at 04:18:26PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Peter Zijlstra wrote:
> > Also, how important is it that subhandler1..n run in their own thread?
> > That is, can't we let them run from the thread that is otherwise waiting
> > for the completino anyway?
> In
On Wed, 22 Jul 2009, Mark Brown wrote:
> On Wed, Jul 22, 2009 at 04:18:26PM +0200, Thomas Gleixner wrote:
> > On Wed, 22 Jul 2009, Peter Zijlstra wrote:
>
> > > Also, how important is it that subhandler1..n run in their own thread?
> > > That is, can't we let them run from the thread that is othe
On Wed, Jul 22, 2009 at 04:52:21PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Mark Brown wrote:
> > The chips I'm deling with can certainly support doing that but I'm not
> > sure there'd be enormous advantages - a lot of the interrupt handlers
> > will either be trivial (eg, RTC ticks o
On Wed, 22 Jul 2009, Mark Brown wrote:
> On Wed, Jul 22, 2009 at 04:52:21PM +0200, Thomas Gleixner wrote:
> > On Wed, 22 Jul 2009, Mark Brown wrote:
>
> > > The chips I'm deling with can certainly support doing that but I'm not
> > > sure there'd be enormous advantages - a lot of the interrupt ha
On Wed, Jul 22, 2009 at 05:15:59PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Mark Brown wrote:
> > That's what they're all doing at present outside of genirq.
> They just are racy against disable/enable/request/free I guess :)
All of them are using a locks which means none of those ca
Hi Thomas,
On Wed, Jul 22, 2009 at 02:58:24PM +0200, Thomas Gleixner wrote:
> Mark,
>
> On Wed, 22 Jul 2009, Mark Brown wrote:
>
> > On Wed, Jul 22, 2009 at 12:44:01PM +0200, Thomas Gleixner wrote:
> > > On Tue, 21 Jul 2009, Mark Brown wrote:
> >
> > > > I'll need to have a more detailed look a
On Wed, 22 Jul 2009, Dmitry Torokhov wrote:
> > I don't think it belongs into the driver code. It belongs into the
> > platform code which sets up the system and knows what's on which
> > interrupt line.
> >
>
> I do think this should be set up by the driver - the platform/arch code
> can't be 1
On Wed, 22 Jul 2009, David Brownell wrote:
> On Tuesday 21 July 2009, Thomas Gleixner wrote:
>
> 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
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 t
On Wed, Jul 22, 2009 at 09:39:32AM -0700, David Brownell wrote:
> 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 fr
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 wo
On Wed, Jul 22, 2009 at 06:40:21PM +0200, Thomas Gleixner wrote:
> If the platform maintainer sets the wrong handler or the wrong
> platform data then it's not the driver writers problem.
It becomes the driver writer's problem as soon as the people writing the
machine integration start e-mailing
On Wednesday 22 July 2009, Thomas Gleixner wrote:
> main interrupt
> hardirq handler wakes main thread handler
>
> main thread handler
> bus magic
> subdevice1 "hardirq" handler wakes subdevice1 irq thread
> subdevice2 "hardirq" handler wakes subdevice2 irq thread
Why for
On Wed, Jul 22, 2009 at 06:40:21PM +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2009, Dmitry Torokhov wrote:
> > > I don't think it belongs into the driver code. It belongs into the
> > > platform code which sets up the system and knows what's on which
> > > interrupt line.
> > >
> >
> > I do
On Wed, Jul 22, 2009 at 10:04:10AM -0700, David Brownell wrote:
> On Wednesday 22 July 2009, Mark Brown wrote:
> > source for a PMIC then we've got generic code that expects to just take
> > a gpio/irq and interact with it.
> Is there a problem with how it works now? GPIO calls come in
> sleepin
On Wednesday 22 July 2009, Mark Brown wrote:
> Yes, I think that'll be required for users like gpiolib. If someone's
> done something like have a button implemented by attaching switch to a
> GPIO input on for something like jack detect on an audio CODEC or a wake
> source for a PMIC then we've go
On Wednesday 22 July 2009, Thomas Gleixner wrote:
>
> > I do think this should be set up by the driver - the platform/arch code
> > can't be 100% certain what model of servicing interrupts driver will
> > chose, nor the driver can know whether arch code set things up for
> > threaded or classic in
On Wednesday 22 July 2009, Thomas Gleixner wrote:
>
> > 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?
>
> Th
On Tuesday 21 July 2009, Thomas Gleixner wrote:
> > > - Multi-function devices like the twl4030 which have an interrupt
> > >controller on them and would like to expose that interrupt controller
> > >via the generic IRQ subsystem. This was a large part of the
> > >discussion in the th
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
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_c
On Wednesday 22 July 2009, Thomas Gleixner wrote:
> 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.
Where "slow" means "access needs to sleep" ... preventing
registe
On Wednesday 22 July 2009, Arve Hjønnevåg wrote:
> 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 regi
2009/7/22 David Brownell :
> On Wednesday 22 July 2009, Arve Hjønnevåg wrote:
>> 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
>> inte
On Wed, Jul 22, 2009 at 11:04:33PM +0200, Thomas Gleixner wrote:
>
> Any more ?
>
Can we also have something like below by any chance?
--
Dmitry
genirq: provide dummy hard irq handler for threaded interrupts
From: Dmitry Torokhov
Quite often drivers using threaded interrupts don't do anyth
> > +static irqreturn_t synaptics_ts_hardirq(int irq, void *dev_id)
> > +{
> > + disable_irq_nosync(irq);
> > + return IRQ_WAKE_THREAD;
>
> Are you sure that this is going to work? The IRQ thread code will not
No, I'm not. I copied it from somewhere and could not really test it.
44 matches
Mail list logo
