Re: Regarding threaded irq

[spinlock cp <spinlock.cp@xxxxxxxxx>]

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 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
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Regards
Spinlock
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies