Regarding threaded irq

[anish singh]

On Thu, Mar 3, 2011 at 10:41 PM, Thomas Petazzoni <
thomas.petazzoni at free-electrons.com> wrote:

> Hello,
>
> On Mon, 28 Feb 2011 21:23:37 +0900
> 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.
>
> Yes. When you return from an IRQ handler, the interrupt is acknowledged
> at the interrupt controller level. So if the interrupt hasn't been
> acknowledged at the device level, then the interrupt will fire again,
> and again, and again. So before threaded IRQ, when you needed to handle
> the IRQ in a thread, the top half would disable the IRQ and wake-up a
> thread. This way, upon return of the IRQ, even if the interrupt is
> ack'ed at the interrupt controller level, it isn't raised again and
> again and again. Later on, when the thread is scheduled, it will ack
> the interrupt at the device level, and re-enable the line.
>
> See for example
>
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L244
> .
> The IRQ is disabled, and the thread is woken up.
>
> Then the thread, implemented at
>
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L180
> ,
> will handle the interrupt, and call
>
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L165
> ,
> which re-enables the IRQ.
>
> > 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?
>
> Correct. As explained in
> http://lxr.free-electrons.com/source/include/linux/interrupt.h#L54.
>
> See for example the driver
>
> http://lxr.free-electrons.com/source/drivers/input/touchscreen/qt602240_ts.c#L677
> .
>
> See also the documentation of request_threaded_irq() at
> http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1011.
>
> Basically, you have two choices :
>
>  *) Your interrupt is not shared. In this case, the "handler" parameter
>    of request_thread_irq() (the hard interrupt handler) can be NULL,
>    and you must pass IRQF_ONESHOT in the flags. As you haven't passed
>    an hard interrupt handler, the default one will be used
>    (irq_default_primary_handler()), which just wakes up the thread.
>
>  *) Your interrupt is shared. In this case, you *must* implement an
>    hard interrupt handler which is responsible for checking whether
>    the interrupt comes from your device or not. If it comes from your
>    device, then you must return IRQ_WAKE_THREAD and disable the
>    interrupt. If it doesn't come from your device, you return IRQ_NONE.
>    See
>    http://lxr.free-electrons.com/source/drivers/mmc/host/jz4740_mmc.c
>    for an example of this use case.
>
> > 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?
>
> Set proper thread priority and scheduling class. But by default, it's
> already in SCHED_FIFO, at priority MAX_USER_RT_PRIO/2. See irq_thread()
> in kernel/irq/manage.c.
>
> > FYI... handler contains some I2C transfer + reporting co-ordinates to
> Input
> > core.
> >
> > Does the above usecase justify changing to threaded_irq??
>
> Yes. See all the touchscreen drivers in drivers/input/touchscreen. Most
> of the I2C/SPI touchscreen drivers are using threaded IRQs.
>
> Regards,
>
> Thomas
>
You did it thomas.It was wonderfully explained and my understanding matches
with the things explained above.

> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110304/5b706a71/attachment-0001.html