Messages in this thread | | | Date | Wed, 2 Jun 2010 00:45:20 -0700 | From | Dmitry Torokhov <> | Subject | Re: Long playing threaded interrupt handlers |
| |
On Wed, Jun 02, 2010 at 09:19:21AM +0200, Thomas Gleixner wrote: > On Wed, 2 Jun 2010, Dmitry Torokhov wrote: > > > HI Thomas, > > > > The threaded IRQ infrastructure that went into the kernel is extremely > > helpful, however in the input land there are quite a few devices that > > require polling after an IRQ has been raised. > > > > Currently most such drivers, instead of threaded interrupts, still use > > [delayed] work to do the polling, and still face the issue of shutting > > down interrupt and scheduled work in a raceless way leaving irq enable > > counter balanced. Is it allowed to have threaded ISR execute for > > extended a amount of time, and do the required polling, provided that > > ISR does certain checks to finish promply in case when we unbind the > > driver or try to suspend the device? > > Sure, why not ?
Great, that is what I wanted to hear!
> The only thing we need to think about is when the poll > is busy polling for a long time, then we need to lower the irq thread > priority to SCHED_OTHER in order not to hog the CPU.
I don't think the drivers will actively polling for a long time, they are likely to poll and then sleep for some time (100-200-300 msecs), so typical loop will be:
handler() { while (!shutdown_or_suspend) { poll_device();
if (all_up) break;
msleep(poll_interval); }
return IRQ_HANDLED; }
Thanks.
-- Dmitry
| |