Regarding threaded irq
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??
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards Spinlock
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards Spinlock
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#.... 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#..., will handle the interrupt, and call http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#..., 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.... 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
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#... . 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#... , will handle the interrupt, and call
http://lxr.free-electrons.com/source/drivers/input/touchscreen/ucb1400_ts.c#... , 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... .
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (3)
-
anish singh -
spinlock cp -
Thomas Petazzoni