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.
Eric
More information about the coreboot
mailing list