Regarding threaded irq

Regarding threaded irq

[anish singh]

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 

Regarding threaded irq

[spinlock cp]

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 

Regarding threaded irq

[anish singh]

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 

Regarding threaded irq

[Thomas Petazzoni]

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

Regarding threaded irq

[anish singh]

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