From mboxrd@z Thu Jan 1 00:00:00 1970 From: anish198519851985@gmail.com (anish singh) Date: Fri, 4 Mar 2011 14:32:35 +0900 Subject: Regarding threaded irq In-Reply-To: <20110303144119.68588d4f@surf> References: <20110303144119.68588d4f@surf> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Thu, Mar 3, 2011 at 10:41 PM, Thomas Petazzoni < thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Mon, 28 Feb 2011 21:23:37 +0900 > anish singh 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