Linux generic IRQ handling¶

Copyright:: © 2005-2010: Thomas Gleixner
Copyright:: © 2005-2006: Ingo Molnar

Introduction¶

The generic interrupt handling layer is designed to provide a completeabstraction of interrupt handling for device drivers. It is able tohandle all the different types of interrupt controller hardware. Devicedrivers use generic API functions to request, enable, disable and freeinterrupts. The drivers do not have to know anything about interrupthardware details, so they can be used on different platforms withoutcode changes.

This documentation is provided to developers who want to implement aninterrupt subsystem based for their architecture, with the help of thegeneric IRQ handling layer.

Rationale¶

The original implementation of interrupt handling in Linux uses the__do_IRQ() super-handler, which is able to deal with every type ofinterrupt logic.

Originally, Russell King identified different types of handlers to builda quite universal set for the ARM interrupt handler implementation inLinux 2.5/2.6. He distinguished between:

Level type
Edge type
Simple type

During the implementation we identified another type:

Fast EOI type

In the SMP world of the__do_IRQ() super-handler another type wasidentified:

Per CPU type

This split implementation of high-level IRQ handlers allows us tooptimize the flow of the interrupt handling for each specific interrupttype. This reduces complexity in that particular code path and allowsthe optimized handling of a given type.

The original general IRQ implementation used hw_interrupt_typestructures and their->ack,->end [etc.] callbacks to differentiatethe flow control in the super-handler. This leads to a mix of flow logicand low-level hardware logic, and it also leads to unnecessary codeduplication: for example in i386, there is anioapic_level_irq and anioapic_edge_irq IRQ-type which share many of the low-level details buthave different flow handling.

A more natural abstraction is the clean separation of the ‘irq flow’ andthe ‘chip details’.

Analysing a couple of architecture’s IRQ subsystem implementationsreveals that most of them can use a generic set of ‘irq flow’ methodsand only need to add the chip-level specific code. The separation isalso valuable for (sub)architectures which need specific quirks in theIRQ flow itself but not in the chip details - and thus provides a moretransparent IRQ subsystem design.

Each interrupt descriptor is assigned its own high-level flow handler,which is normally one of the generic implementations. (This high-levelflow handler implementation also makes it simple to providedemultiplexing handlers which can be found in embedded platforms onvarious architectures.)

The separation makes the generic interrupt handling layer more flexibleand extensible. For example, an (sub)architecture can use a genericIRQ-flow implementation for ‘level type’ interrupts and add a(sub)architecture specific ‘edge type’ implementation.

To make the transition to the new model easier and prevent the breakageof existing implementations, the__do_IRQ() super-handler is stillavailable. This leads to a kind of duality for the time being. Over timethe new model should be used in more and more architectures, as itenables smaller and cleaner IRQ subsystems. It’s deprecated for threeyears now and about to be removed.

Known Bugs And Assumptions¶

None (knock on wood).

Abstraction layers¶

There are three main levels of abstraction in the interrupt code:

High-level driver API
High-level IRQ flow handlers
Chip-level hardware encapsulation

Interrupt control flow¶

Each interrupt is described by an interrupt descriptor structureirq_desc. The interrupt is referenced by an ‘unsigned int’ numericvalue which selects the corresponding interrupt description structure inthe descriptor structures array. The descriptor structure containsstatus information and pointers to the interrupt flow method and theinterrupt chip structure which are assigned to this interrupt.

Whenever an interrupt triggers, the low-level architecture code callsinto the generic interrupt code by calling desc->handle_irq(). Thishigh-level IRQ handling function only uses desc->irq_data.chipprimitives referenced by the assigned chip descriptor structure.

High-level Driver API¶

The high-level Driver API consists of following functions:

See the autogenerated function documentation for details.

High-level IRQ flow handlers¶

The generic layer provides a set of pre-defined irq-flow methods:

The interrupt flow handlers (either pre-defined or architecturespecific) are assigned to specific interrupts by the architecture eitherduring bootup or during device initialization.

Default flow implementations¶

Helper functions¶

The helper functions call the chip primitives and are used by thedefault flow implementations. The following helper functions areimplemented (simplified excerpt):

default_enable(struct irq_data *data){    desc->irq_data.chip->irq_unmask(data);}default_disable(struct irq_data *data){    if (!delay_disable(data))        desc->irq_data.chip->irq_mask(data);}default_ack(struct irq_data *data){    chip->irq_ack(data);}default_mask_ack(struct irq_data *data){    if (chip->irq_mask_ack) {        chip->irq_mask_ack(data);    } else {        chip->irq_mask(data);        chip->irq_ack(data);    }}noop(struct irq_data *data){}