Prev: [PATCH 11/26] rtmutex: Convert wait_lock and pi_lock to raw_spinlock
Next: [resend][PATCH] mm, lockdep: annotate reclaim context to zone reclaim too
From: Mahalingam, Nithish on 13 Feb 2010 09:40
Hi Anton,

First of all apologize for not sticking to my word to get back with
the patch as promised. Got tied up with some important work and could
not spend time on this patch.

I have started making changes today and will be testing it out after
the weekend. Will post the patch for review by mid next week for sure.

OK now to a question I had while working on the patch:

>>> + schedule_work(&pbi->handler);
>>
>> I think you can use threaded irq for this.
>>
>> See documentation for request_threaded_irq() in kernel/irq/manage.c.
>> And as an example of usage see drivers/mfd/wm8350-irq.c.
>
> Haa that is useful information... completely missed to read about this
> feature. Will modify the code to make use of threaded IRQ.

I have a very peculiar case - My hardware muxes 8 different types of
battery interrupts as one before forwarding it. I do the interrupt
de-muxing in the driver to find its real source; because I do this I
had used workqueue to make sure I do not keep the battery interrupt
source disabled for a long time and won't potential miss a battery
interrupt.
I was reading the request_threaded_irq code and found that only
when the threaded function returns interrupt should be re-enabled
(as it is suggested in the APIs function comment). Now if I do this,
won't I potential miss a interrupt?

Also I failed to understand what exact scenario request_threaded_irq
is useful over having a workqueue spawned inside a interrupt handler?
Is it only when you want to hold the interrupt EOI until the threaded
function returns?

Please shout back if I am making some stupid assumptions here.

Regards,
Nithish Mahalingam

First  |  Prev  | 
Pages: 1 2
Prev: [PATCH 11/26] rtmutex: Convert wait_lock and pi_lock to raw_spinlock
Next: [resend][PATCH] mm, lockdep: annotate reclaim context to zone reclaim too