Regarding threaded irq

[spinlock cp]

Hi Anish



On Mon, Feb 28, 2011 at 5:53 PM, anish singh <anish198519851985 at 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


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

Regards
Spinlock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110301/63ff7925/attachment.html