Does Linux kernel disables any Interrupts while going into IRQ handler?

Does Linux kernel disables any Interrupts while going into IRQ handler?

[priyaranjan]

When an Interrupt occurs most device drivers creates a critical section
using spin_lock_irqsave or spin_lock_irq which disables the interrupt.

In such a case the Interrupts are disabled by the IRQ handler. My question
is whether Linux kernel disables any interrupts just when the IRQ handler
executes or it just wait for the IRQ handler programmer to disable the IRQ
in whatever way?

My understanding is that Russel King has implemented IRQ_DISABLED, If this
flag is set then only the IRQ that has occurred is disabled lately however
enabled automatically by Kernel after IRQ handler finishes. Is that
correct? This also happens in delayed manner.Can anyone explain me how
exactly the IRQ disabling is delayed?

>From free-electrons link
<http://free-electrons.com/kerneldoc/latest/DocBook/genericirq/Highlevel_IRQ_flow_handlers.html>,
what I read is :-

*The interrupt is kept enabled and is masked in the flow handler when an
interrupt event happens*. This prevents losing edge interrupts on hardware
which does not store an edge interrupt event while the interrupt is
disabled at the hardware level.

Can anyone please explain the bold line here?

Regards,

Priyaranjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160224/cb7779d5/attachment.html 

Does Linux kernel disables any Interrupts while going into IRQ handler?

[jonathan nifenecker]

Hi,

I'll give a try on this one, I've just getting interested in the kernel,
but have a very good knowledge of microcontroller and think I can enlighten
you with some hardware explanation on that :

when an interrupt occur and is enabled, a flag is set at the hardware level
in some interrupt flag register. (this register is set to 1 by hardware
only, the software may only clear it to 0 to acknowledge the interrupt has
been treated. It may be automatically cleared when the interrupt handler
launch the appropriate function call.)

The "mask" in your bold citation is another register, the interrupt mask
register. It allow to control temporarily the execution of particular
interrupt on a case by case basis. thus letting other interrupt occurs
while preventing a particular one. (this register is set by software, you
can think of it as an "interrupt handler inhibitor register" )

Those 2 register are wired into a bitwise AND before the signal arrived in
the interrupt handler. the interrupt handler launch the appropriate
function call corresponding to an interrupt signal received.

So because of the AND logic, if the interrupt mask bit is 0 for a specific
interrupt, the interrupt handler will see no positive edge whatever the
interrupt occurred.
BUT If the interrupt occurred, the interrupt flag will still be set to 1,
and not loose the information of an interrupt occurred.

If you set back the mask to 1, 1 AND 1 =1 the signal will then propagate to
the interrupt handler and the function call will be launch right away !


wikipedia on Mask <https://en.wikipedia.org/wiki/Mask_%28computing%29>.
What may be confuse here is that the bitwise operation can be executed
completely by the hardware (instant reactivity), so you are dealing with
mask without seeing  interrupt_flag ^ interrupt_mask anywhere in the code.

Hope that help.


Jonathan

2016-02-24 13:14 GMT+01:00 priyaranjan <priyaranjan45678@gmail.com>:

> When an Interrupt occurs most device drivers creates a critical section
> using spin_lock_irqsave or spin_lock_irq which disables the interrupt.
>
> In such a case the Interrupts are disabled by the IRQ handler. My question
> is whether Linux kernel disables any interrupts just when the IRQ handler
> executes or it just wait for the IRQ handler programmer to disable the IRQ
> in whatever way?
>
> My understanding is that Russel King has implemented IRQ_DISABLED, If this
> flag is set then only the IRQ that has occurred is disabled lately however
> enabled automatically by Kernel after IRQ handler finishes. Is that
> correct? This also happens in delayed manner.Can anyone explain me how
> exactly the IRQ disabling is delayed?
>
> From free-electrons link
> <http://free-electrons.com/kerneldoc/latest/DocBook/genericirq/Highlevel_IRQ_flow_handlers.html>,
> what I read is :-
>
> *The interrupt is kept enabled and is masked in the flow handler when an
> interrupt event happens*. This prevents losing edge interrupts on
> hardware which does not store an edge interrupt event while the interrupt
> is disabled at the hardware level.
>
> Can anyone please explain the bold line here?
>
> Regards,
>
> Priyaranjan
>
> _______________________________________________
> 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/20160224/2230720a/attachment.html