<br><br>
<div class="gmail_quote">On Thu, Mar 3, 2011 at 10:41 PM, Thomas Petazzoni <span dir="ltr"><<a href="mailto:thomas.petazzoni@free-electrons.com">thomas.petazzoni@free-electrons.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hello,<br><br>On Mon, 28 Feb 2011 21:23:37 +0900<br>
<div class="im">anish singh <<a href="mailto:anish198519851985@gmail.com">anish198519851985@gmail.com</a>> wrote:<br><br></div>
<div class="im">> I have a touch driver which is not yet using threded_irq.So i am planning to<br>> change it to<br>> use threaded_irq.<br>><br>> In the current handler they are first disabling the irq line and then<br>
> calling the single threaded<br>> workqueue to do the rest of the task and when the task is completed i.e. in<br>> the end of workqueue<br>> function they are enabling the irq line.<br><br></div>Yes. When you return from an IRQ handler, the interrupt is acknowledged<br>
at the interrupt controller level. So if the interrupt hasn't been<br>acknowledged at the device level, then the interrupt will fire again,<br>and again, and again. So before threaded IRQ, when you needed to handle<br>
the IRQ in a thread, the top half would disable the IRQ and wake-up a<br>thread. This way, upon return of the IRQ, even if the interrupt is<br>ack'ed at the interrupt controller level, it isn't raised again and<br>
again and again. Later on, when the thread is scheduled, it will ack<br>the interrupt at the device level, and re-enable the line.<br><br>See for example<br><a href="http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L244" target="_blank">http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L244</a>.<br>
The IRQ is disabled, and the thread is woken up.<br><br>Then the thread, implemented at<br><a href="http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L180" target="_blank">http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L180</a>,<br>
will handle the interrupt, and call<br><a href="http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L165" target="_blank">http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#L165</a>,<br>
which re-enables the IRQ.<br>
<div class="im"><br>> So my question is if i change it to use threaded_irq.In the handler should i<br>> also enable or disable<br>> the irq as is done in the case of present handler OR i don't need to do this<br>
> step?<br>> ---i think IRQF_ONESHOT will do this for me right?<br><br></div>Correct. As explained in<br><a href="http://lxr.free-electrons.com/source/include/linux/interrupt.h#L54" target="_blank">http://lxr.free-electrons.com/source/include/linux/interrupt.h#L54</a>.<br>
<br>See for example the driver<br><a href="http://lxr.free-electrons.com/source/drivers/input/touchscreen/qt602240_ts.c#L677" target="_blank">http://lxr.free-electrons.com/source/drivers/input/touchscreen/qt602240_ts.c#L677</a>.<br>
<br>See also the documentation of request_threaded_irq() at<br><a href="http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1011" target="_blank">http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1011</a>.<br>
<br>Basically, you have two choices :<br><br> *) Your interrupt is not shared. In this case, the "handler" parameter<br> of request_thread_irq() (the hard interrupt handler) can be NULL,<br> and you must pass IRQF_ONESHOT in the flags. As you haven't passed<br>
an hard interrupt handler, the default one will be used<br> (irq_default_primary_handler()), which just wakes up the thread.<br><br> *) Your interrupt is shared. In this case, you *must* implement an<br> hard interrupt handler which is responsible for checking whether<br>
the interrupt comes from your device or not. If it comes from your<br> device, then you must return IRQ_WAKE_THREAD and disable the<br> interrupt. If it doesn't come from your device, you return IRQ_NONE.<br> See<br>
<a href="http://lxr.free-electrons.com/source/drivers/mmc/host/jz4740_mmc.c" target="_blank">http://lxr.free-electrons.com/source/drivers/mmc/host/jz4740_mmc.c</a><br> for an example of this use case.<br>
<div class="im"><br>> I want this threaded handler to be executing as soon as possible as i want<br>> the latency between the<br>> touch by the user and response to be minimum.Is there any way to achieve<br>> this?<br>
<br></div>Set proper thread priority and scheduling class. But by default, it's<br>already in SCHED_FIFO, at priority MAX_USER_RT_PRIO/2. See irq_thread()<br>in kernel/irq/manage.c.<br>
<div class="im"><br>> FYI... handler contains some I2C transfer + reporting co-ordinates to Input<br>> core.<br>><br>> Does the above usecase justify changing to threaded_irq??<br><br></div>Yes. See all the touchscreen drivers in drivers/input/touchscreen. Most<br>
of the I2C/SPI touchscreen drivers are using threaded IRQs.<br><br>Regards,<br><br>Thomas<br></blockquote>
<div>You did it thomas.It was wonderfully explained and my understanding matches with the things explained above.</div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><font color="#888888">--<br>Thomas Petazzoni, Free Electrons<br>Kernel, drivers, real-time and embedded Linux<br>
development, consulting, training and support.<br><a href="http://free-electrons.com/" target="_blank">http://free-electrons.com</a><br></font>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>Kernelnewbies mailing list<br><a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br><a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</div></div></blockquote></div><br>