Hi,
Sorry about my previous post in HTML.
On Thu, Mar 7, 2013 at 9:40 AM, <Valdis.Kletnieks@xxxxxx> wrote:
>
> On Thu, 07 Mar 2013 09:28:58 -0800, Dave Hylands said:
>
> > In my experience, edges triggered interrupts are always latched by the HW
> > when they arrive. If another edge comes along between the initial edge and
> > the time that the interrupt is cleared, then this second edge is lost. The
> > fact that an interrupt is pending will still be retained though, and as
> > soon as interrupts are enabled, then the interrupt handler will fire.
>
> Actually, what you're describing there is hardware that converts edge
> triggered to level triggered precisely because edge triggered stuff
> sucks otherwise. ;)
Sorry about my previous post in HTML.
On Thu, Mar 7, 2013 at 9:40 AM, <Valdis.Kletnieks@xxxxxx> wrote:
>
> On Thu, 07 Mar 2013 09:28:58 -0800, Dave Hylands said:
>
> > In my experience, edges triggered interrupts are always latched by the HW
> > when they arrive. If another edge comes along between the initial edge and
> > the time that the interrupt is cleared, then this second edge is lost. The
> > fact that an interrupt is pending will still be retained though, and as
> > soon as interrupts are enabled, then the interrupt handler will fire.
>
> Actually, what you're describing there is hardware that converts edge
> triggered to level triggered precisely because edge triggered stuff
> sucks otherwise. ;)
The HW is just a flipflop. All of the ARM/MIPS processors I've worked with include this. If there is a processor which doesn't include this, then yeah, edge triggered interrupts would be almost impossible to deal with reliably.
One other difference between edge and level triggered interrupts is that with level triggered interrupts, if an interrupt is asserted while interrupts are disabled/masked and it becomes deasserted before interrupts are enabled/unmasked then that interrupt will be lost.
This is pathalogical, since the interrupt shouldn't get deasserted on its own, it normally requires that the driver access some register or something to deassert the interrupt. I guess it could also happen if you have a device which generated a short pulse (typically what edge-triggered devices would do) and the processor was configured to use a level triggered interrupt.
This is pathalogical, since the interrupt shouldn't get deasserted on its own, it normally requires that the driver access some register or something to deassert the interrupt. I guess it could also happen if you have a device which generated a short pulse (typically what edge-triggered devices would do) and the processor was configured to use a level triggered interrupt.
If you code the driver properly, there is really very little difference between edge and level triggered interrupts when you're dealing with a single device driving the interrupt line. A level triggered interrupt is really just an edge triggered interrupt with a long assertion time :)
Both edge and level triggered will miss interrupts if the interrupt arrival rate is faster than the interrupt handler can deal with.
I guess one place where things gets different is when you're dealing with offchip peripherals. Say you have an ADC chip sitting on a SPI bus. If it generated a level triggered interrupt, then you need to actually send a SPI command to the chip to clear the interrupt. With edge triggered interrupts you don't "need" to send a command, unless the chip otherwise requires it (it may still have some type of status register which requires clearing before the chip generates another interrupt).
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
