Tarl Neustaedter <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
