On Wed, May 19, 2010 at 3:37 PM, Scott Wood <[email protected]> wrote: > On 05/19/2010 04:27 PM, Grant Likely wrote: >> >> On Mon, May 3, 2010 at 10:34 AM, Scott Wood<[email protected]> >> wrote: >>> >>> Grant Likely wrote: >>>>> >>>>> + // IPIC >>>>> + // interrupts cell =<intr #, sense> >>>>> + // sense values match linux IORESOURCE_IRQ_* defines: >>>>> + // sense == 8: Level, low assertion >>>>> + // sense == 2: Edge, high-to-low change >>>>> + // >>>>> + ipic: interrupt-control...@c00 { >>>>> + compatible = "fsl,mpc5121-ipic", "fsl,ipic"; >>>>> + interrupt-controller; >>>>> + #address-cells =<0>; >>>> >>>> Don't need #address-cells here >>> >>> #address-cells is required by ePAPR for interrupt controllers if an >>> interrupt-map is used. >> >> Why? >> >> /me is too lazy to dig out ePAPR and look. > > Address cells are part of the interrupt identification. Typically with > interrupt maps this is only used on the child end (e.g. to select a > particular PCI slot), but if the parent interrupt controller's address cells > are non-zero it will be expected in the parent interrupt specifier as well. > > I believe the only part of this that is new with ePAPR is that it asks that > the interrupt controller address cells be explicitly specified, as it's a > bit icky for it to default to 2 in some contexts and 0 in others.
Hmmm. I've not seen that before. On the 5200 the value of #address-cells for interrupt controllers has apparently defaulted to <0> so I've never encountered or thought about it. I'm not even sure what #address-cells != 0 would mean in the context of interrupt mapping, or where it would be relevant. g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
