On Tue, Mar 1, 2011 at 2:11 PM, spinlock cp <spinlock.cp@xxxxxxxxx> wrote:
Hi Anish
On Mon, Feb 28, 2011 at 5:53 PM, anish singh <anish198519851985@xxxxxxxxx> wrote:
I have a touch driver which is not yet using threded_irq.So i am planning to change it touse threaded_irq.ÂIn the current handler they are first disabling the irq line and then calling theÂsingle threadedworkqueue to do the rest of the task and when the task is completed i.e. in the end of workqueuefunction 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 disablethe 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 thetouch 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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards
Spinlock
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
