Handling interrupt routing cleanly...

Eric W. Biederman ebiederman at lnxi.com
Wed Feb 4 18:43:01 CET 2004

Tarl Neustaedter <Tarl.Neustaedter at sun.com> writes:

> > I seem to be dropping into this conversation late; What do you
> > mean that there is a single root for the interrupt tree?
> Ah. Never mind, I found it:
> Eric W. Biederman wrote:
> [...]
>  > Each device has it's interrupt.
> Plural. We have a number of devices which generate multiple interrupts.
> On PCI, that usually means being constrained to four interrupts, but
> for on-board devices we can deal with whole bunches of interrupt lines
> per device.

That part I could not quite understand when reading the OF spec.  How
you can have multiple values per property.  Base address registers
seemed to have the same problem.

>  > Each device has an interrupt parent.
>  >   If not specified explicitly the interrupt parent is simply up
>  >   the device tree but that was not required.
> Device-tree parent is default, but not required.

What I was saying.

>  > An interrupt parent can have an interrupt mapping table
>  >   that maps interrupts maps device#/interrupt pairs to ids
>  >   consumed by devices up the interrupt tree.
> It allows routing interrupts to anywhere else in the device
> tree. This construct was added explicitly because of hardware
> engineer's tendency to build boards which route interrupts
> differently than the datapaths, and we needed some way to
> deal with it. Since they weren't going to constrain themselves
> to a hierarchical structure for interrupts, we couldn't
> constrain the interrupt-map, either.

Right, and the same applies to today boards until everyone
transitions to pci express and hypertransport exclusively.

The only interesting thing I have is that in when using
APICs interrupts are routed differently than when using
the legacy x86 PIC.   I think we can use two intertwined
interrupt trees to model this.


More information about the coreboot mailing list