On Fri, 2012-04-20 at 14:04 -0500, Scott Wood wrote: > That's not supposed to be how device tree bindings are determined.
Ugh ? This is nothing to do with Linux, I think Kumar is confused :-) This has to do with PCI bindings. If you put the interrupt-map in the parent, then crossing the virtual p2p will cause a swizzling which is not what you want. As long as the device has a device number (in devfn) of 0 that's fine but that may not always be the case. > It's causing us problems with virtualization device assignment, because > if we just assign the parent bus we don't get the interrupt map, but if > we assign the child we need to deal with what it means to assign an > individual PCI device (e.g. on our internal KVM stuff we get an error on > that reg property). I'm not sure what you are doing with device-assignement in KVM, we are doing something different for server I suppose since the existing assignment code in qemu-kvm is a dead end... But you should probably synthetize an interrupt-map for the guest. > What does this node represent in the first place? Is there really a > PCI-to-PCI bridge? Are all other PCI devices underneath it? Yes, PCIe 101 :-) It's the root complex, it's "virtual" in that it's a construct of the host bridge, there's no physical "bridge" in the system, but yes, PCIe always has a virtual P2P at the top to represent the root complex. This was done to fix the long standing problem that there wasn't a proper way to represent host bridges as parent of their devices in PCI land. It allows PCIe to guarantee that a device always has a bridge above itself, with the corresponding link control registers etc... which is useful for point to point links :-) That's also why for example PCIe switches look like stacks of bridges, for example, a 2 fork switch looks like: | P2P / \ P2P P2P | | That way each downstream device gets its own parent P2P with the corresponding PCIe link control registers etc... > >> Do we really need the error interrupt specified twice? > > > > I put it twice because it has multiple purposes, one has to do with > > interrupts defined by the PCI spec vs ones defined via FSL controller. > > There are PCI-defined error condition s that cause a host controller > interrupt. What does this have to do with the bridge node? > > >> Why is there a zeroed out reg property: reg = <0 0 0 0 0> ?? > > > > scratching my head, what happens if you remove it? > > Sigh. As I said earlier, this is not some black magic, it's a proper reg value for the root complex virtual bridge. It has bus 0, devfn 0, so the reg property for the config space has a value of 0. Without it, the kernel won't properly match it to the corresponding pci_dev. Cheers, Ben. > -Scott > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev