On Thu, Mar 3, 2011 at 10:41 PM, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote:
Hello,
On Mon, 28 Feb 2011 21:23:37 +0900
> I have a touch driver which is not yet using threded_irq.So i am planning toYes. When you return from an IRQ handler, the interrupt is acknowledged
> 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.
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.
Correct. As explained in
> 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?
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.
Set proper thread priority and scheduling class. But by default, it's
> 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?
already in SCHED_FIFO, at priority MAX_USER_RT_PRIO/2. See irq_thread()
in kernel/irq/manage.c.
Yes. See all the touchscreen drivers in drivers/input/touchscreen. Most
> FYI... handler contains some I2C transfer + reporting co-ordinates to Input
> core.
>
> Does the above usecase justify changing to threaded_irq??
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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
