[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7N6vqxnKbzm=iepjtOq0bZQhkFBjsWe6qhWnqOJtGxgKrT9w@mail.gmail.com>
Date: Tue, 18 Sep 2012 14:38:26 +0530
From: anish singh <anish198519851985@...il.com>
To: "Liu, Chuansheng" <chuansheng.liu@...el.com>
Cc: "'linux-kernel@...r.kernel.org' (linux-kernel@...r.kernel.org)"
<linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH] genirq: Add the IRQS_ONESHOT support for edge interrupt
On Tue, Sep 18, 2012 at 12:51 PM, Liu, Chuansheng
<chuansheng.liu@...el.com> wrote:
>> This comment might help.
>> kernel/irq/manage.c
>>
>> } else if (new->handler == irq_default_primary_handler) {
>>
>> /*
>> * The interrupt was requested with handler = NULL, so
>> * we use the default primary handler for it. But it
>> * does not have the oneshot flag set. In combination
>> * with level interrupts this is deadly, because the
>> * default primary handler just wakes the thread, then
>> * the irq lines is reenabled, but the device still
>> * has the level irq asserted. Rinse and repeat....
>> *
>> * While this works for edge type interrupts, we play
>> * it safe and reject unconditionally because we can't
>> * say for sure which type this interrupt really
>> * has. The type flags are unreliable as the
>> * underlying chip implementation can override them.
>> */
>
> This is not my case. My request_irq is as below:
> request_threaded_irq(drv_data->irq,
> func1,
> func2,
> IRQF_SHARED|IRQS_ONESHOT ,
> "AAAA",
> drv_data);
I hope you are disabling the interrupt in your primary handler and returning
IRQ_WAKE_THREAD.
If yes then someone with experience in this interrupt handling code
can help you.
--
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