pci node question
Benjamin Herrenschmidt
benh at kernel.crashing.org
Sat Apr 21 07:19:09 EST 2012
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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
More information about the Linuxppc-dev
mailing list