* Regarding threaded irq @ 2011-02-28 12:23 anish singh 2011-03-01 5:11 ` spinlock cp 2011-03-03 13:41 ` Thomas Petazzoni 0 siblings, 2 replies; 5+ messages in thread From: anish singh @ 2011-02-28 12:23 UTC (permalink / raw) To: kernelnewbies 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. 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? 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? FYI... handler contains some I2C transfer + reporting co-ordinates to Input core. Does the above usecase justify changing to threaded_irq?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110228/ca184200/attachment.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Regarding threaded irq 2011-02-28 12:23 Regarding threaded irq anish singh @ 2011-03-01 5:11 ` spinlock cp 2011-03-01 5:19 ` anish singh 2011-03-03 13:41 ` Thomas Petazzoni 1 sibling, 1 reply; 5+ messages in thread From: spinlock cp @ 2011-03-01 5:11 UTC (permalink / raw) To: kernelnewbies Hi Anish On Mon, Feb 28, 2011 at 5:53 PM, anish singh <anish198519851985@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. > > > 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? > There could be a very good reason, why IRQ were disabled at entry and re-enabled at exit in workqueue. For example if, workqueue is acquiring the spinlock and which is expected to be acquired by ISR also. Probably you should reason why irq were disabled/enabled in work queue and redesign your threded_irq accordingly > 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? > > FYI... handler contains some I2C transfer + reporting co-ordinates to Input > core. > > Does the above usecase justify changing to threaded_irq?? > > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > Regards Spinlock -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110301/63ff7925/attachment.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Regarding threaded irq 2011-03-01 5:11 ` spinlock cp @ 2011-03-01 5:19 ` anish singh 0 siblings, 0 replies; 5+ messages in thread From: anish singh @ 2011-03-01 5:19 UTC (permalink / raw) To: kernelnewbies On Tue, Mar 1, 2011 at 2:11 PM, spinlock cp <spinlock.cp@gmail.com> wrote: > Hi Anish > > > > On Mon, Feb 28, 2011 at 5:53 PM, anish singh <anish198519851985@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. >> >> > >> 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? >> > > There could be a very good reason, why IRQ were disabled at entry and > re-enabled at exit in workqueue. > For example if, workqueue is acquiring the spinlock and which is expected > to be acquired by ISR also. > Probably you should reason why irq were disabled/enabled in work queue and > redesign your threded_irq accordingly > IRQ line is disabled as we can't don't support nested interrupt for our touch interrupt handler.I think threaded_irq with flag IRQF_ONESHOT will do this for me? > > >> 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? >> >> FYI... handler contains some I2C transfer + reporting co-ordinates to >> Input core. >> >> Does the above usecase justify changing to threaded_irq?? >> > You didn't answer this question. > >> >> >> >> > > >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > > Regards > Spinlock > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110301/9be178f6/attachment.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Regarding threaded irq 2011-02-28 12:23 Regarding threaded irq anish singh 2011-03-01 5:11 ` spinlock cp @ 2011-03-03 13:41 ` Thomas Petazzoni 2011-03-04 5:32 ` anish singh 1 sibling, 1 reply; 5+ messages in thread From: Thomas Petazzoni @ 2011-03-03 13:41 UTC (permalink / raw) To: kernelnewbies Hello, On Mon, 28 Feb 2011 21:23:37 +0900 anish singh <anish198519851985@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 -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Regarding threaded irq 2011-03-03 13:41 ` Thomas Petazzoni @ 2011-03-04 5:32 ` anish singh 0 siblings, 0 replies; 5+ messages in thread From: anish singh @ 2011-03-04 5:32 UTC (permalink / raw) To: kernelnewbies 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 <anish198519851985@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-04 5:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-28 12:23 Regarding threaded irq anish singh 2011-03-01 5:11 ` spinlock cp 2011-03-01 5:19 ` anish singh 2011-03-03 13:41 ` Thomas Petazzoni 2011-03-04 5:32 ` anish singh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).