On Tue, Mar 1, 2011 at 2:11 PM, spinlock cp <spinlock.cp@gmail.com> wrote:
Hi Anish
On Mon, Feb 28, 2011 at 5:53 PM, anish singh <anish198519851985@gmail.com
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
IRQ line is disabled as we can't don't support nested interrupt for our touch interrupt handler.I think threaded_irq with flag IRQF_ONESHOT will do this for me?
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??
You didn't answer this question.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards Spinlock