Interrupt handler latency and Interrupt handling issues

Interrupt handler latency and Interrupt handling issues

[Singaravelan Nallasellan]

I have an issue in determining the source of the interrupt due to the
latency to access the register. The driver needs to send an read
request to another kernel driver. The other driver will use an
Indirect IO read to through an IO port. It will could also potentially
generate interrupt. It will lead to the latency issues in the
interrupt handler.

The driver may not be able to realiably identify the source of the
interrupt before coming out of the IRQ handler if it has to come out
the handler within a letency period.  Because of this, The driver will
not be able to say IRQ handled before coming out of the handler. If
the driver says IRQ handled assuming that the interrupt belongs to it,
it could also cause conflict with the other interrupt handler
registered for the same interrupt.

I am planning to say that IRQ handled in the Interrupt handler and
schedule a work queue to handle the identification and handling. Does
anybody see issues here? Are there any better mechanism to handle this
case?

Is there any latency requirements from the kernel?

How much is the tolerable latency for the interrupt handlers?

Thanks

Re: Interrupt handler latency and Interrupt handling issues

[Robert Hancock]

Singaravelan Nallasellan wrote:
> I have an issue in determining the source of the interrupt due to the
> latency to access the register. The driver needs to send an read
> request to another kernel driver. The other driver will use an
> Indirect IO read to through an IO port. It will could also potentially
> generate interrupt. It will lead to the latency issues in the
> interrupt handler.
> 
> The driver may not be able to realiably identify the source of the
> interrupt before coming out of the IRQ handler if it has to come out
> the handler within a letency period.  Because of this, The driver will
> not be able to say IRQ handled before coming out of the handler. If
> the driver says IRQ handled assuming that the interrupt belongs to it,
> it could also cause conflict with the other interrupt handler
> registered for the same interrupt.

The driver does not need to determine exactly if its device caused the 
interrupts (with some devices it's not even possible to tell for sure). 
You can always say IRQ_HANDLED if you can't tell. This doesn't affect 
whether other IRQ handlers on that interrupt will be called. The only 
downside is that the screaming IRQ detection won't work on that IRQ 
since that driver always says it handled the interrupt.

> 
> I am planning to say that IRQ handled in the Interrupt handler and
> schedule a work queue to handle the identification and handling. Does
> anybody see issues here? Are there any better mechanism to handle this
> case?
> 
> Is there any latency requirements from the kernel?
> 
> How much is the tolerable latency for the interrupt handlers?