Tarl Neustaedter Tarl.Neustaedter@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