Hello,

On Mon, 28 Feb 2011 21:23:37 +0900
anish singh [off-list ref] 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com