Re: Threaded interrupt handlers broken?

[Michael Buesch]

On Sunday 16 August 2009 15:22:29 Thomas Gleixner wrote:
> On Sun, 16 Aug 2009, Michael Buesch wrote:
> > On Sunday 16 August 2009 12:14:36 Michael Buesch wrote:
> > I need the following patch for threaded IRQs to work.
> > The first hunk obviously is incorrect. But without it the thread_fn is
> > never called.
> > 
> > Index: wireless-testing/kernel/irq/manage.c
> > ===================================================================
> > --- wireless-testing.orig/kernel/irq/manage.c	2009-08-15 22:22:07.000000000 +0200
> > +++ wireless-testing/kernel/irq/manage.c	2009-08-16 14:05:23.000000000 +0200
> > @@ -504,7 +504,7 @@ static int irq_thread(void *data)
> >  		atomic_inc(&desc->threads_active);
> >  
> >  		spin_lock_irq(&desc->lock);
> > -		if (unlikely(desc->status & IRQ_DISABLED)) {
> > +		if (0&&unlikely(desc->status & IRQ_DISABLED)) {
> 
> So the interrupt is marked disabled. How do you setup the handler ?
> And what does the primary handler do ? Can you post your driver code please?

This patch converts the b43 driver to threaded interrupts:
http://bu3sch.de/patches/wireless-testing/20090816-1535/patches/002-b43-threaded-irq-handler.patch

It kind of works with this hack applied to kernel/irq/manage.c

> >  			/*
> >  			 * CHECKME: We might need a dedicated
> >  			 * IRQ_THREAD_PENDING flag here, which
> > @@ -520,7 +520,7 @@ static int irq_thread(void *data)
> >  			action->thread_fn(action->irq, action->dev_id);
> >  		}
> >  
> > -		wake = atomic_dec_and_test(&desc->threads_active);
> > +		wake = !atomic_dec_and_test(&desc->threads_active);
> 
> So you wake when the thread counter is != 0 after the decrement.
> 
>  #define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0)

Yeah, isn't that what we want to do? I read the test as "wake other threads,
if there are other threads" or something like that.

-- 
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/