Hi Anish
On Mon, Feb 28, 2011 at 5:53 PM, anish singh <[email protected]>wrote: > I have a touch driver which is not yet using threded_irq.So i am planning > to change it to > use threaded_irq. > > In the current handler they are first disabling the irq line and then > calling the single threaded > workqueue to do the rest of the task and when the task is completed i.e. in > the end of workqueue > function they are enabling the irq line. > > > So my question is if i change it to use threaded_irq.In the handler should > i also enable or disable > the irq as is done in the case of present handler OR i don't need to do > this step? > ---i think IRQF_ONESHOT will do this for me right? > There could be a very good reason, why IRQ were disabled at entry and re-enabled at exit in workqueue. For example if, workqueue is acquiring the spinlock and which is expected to be acquired by ISR also. Probably you should reason why irq were disabled/enabled in work queue and redesign your threded_irq accordingly > I want this threaded handler to be executing as soon as possible as i want > the latency between the > touch by the user and response to be minimum.Is there any way to achieve > this? > > FYI... handler contains some I2C transfer + reporting co-ordinates to Input > core. > > Does the above usecase justify changing to threaded_irq?? > > > > > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > Regards Spinlock
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
