Re: pci node question

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Between the root complex and whatever's plugged in?

Yes.

> > so that is what the node represents.  Its always been a bit confusing to me as its not 100% standardized by PCI sig.

It's absolutely standard. The only case where you have "siblings" to
that RC is when it's some kind of integrated chipset with non-PCI
devices in it (still common in Intel world).

Any real PCIe device -must- have a P2P above it with the PCIe capability
& associated control registers.

> Is it documented anywhere (e.g. in the chip manual)?  Is it common (even
> if 100% standardized), or a Freescale-ism?

PCIe spec.

> Is there an actual PCIe-to-PCIe bridge that shows up in the root
> complex's config space

Yes.

>  (not talking about the host bridge PCI device
> that has always been there on FSL PCI controllers, which we didn't
> represent in the device tree on non-express PCI)?  Why does this bridge
> need to be represented in the device tree (assuming no ISA devices need
> to be represented), when other PCI devices (including bridges) don't?

You don't have to, but we sometimes do it so we can put the
interrupt-map in the right place. But again, since on PCIe the device
underneath should always have dev 0 for non-SRIOV stuff, the swizzling
shall be NOP and so having the interrupt-map all the way at the top
might work. However I'm not sure if that will work with PFs and ARI
where the dev is non-0.

> > Maybe Ben's got some comments to add here from a generic PCIe point of view.
> > 
> >>>> 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 conditions that cause a host controller
> >> interrupt.  What does this have to do with the bridge node?
> > 
> > Think of the "error" IRQ as shared between to classes of interrupts.  One set are controller errors defined by FSL, the other are errors defined by PCI sig / bus point of view.
> > 
> > I'd expect controller errors to be handled by something like EDAC would bind at "fsl,qoriq-pcie-v2.2" level node.  The PCI bus code would looks at the virtual bridge down.
> 
> This shouldn't be about where a specific piece of Linux code looks.
> 
> I don't see why the split of PCI-defined errors versus FSL-defined
> errors maps to bridge node versus controller node.  What if we didn't
> have the bridge?  We'd still have PCI-defined errors, right?

The linux generic PCIe port driver looks for the interrupt of the bridge
for standardized PCIe AER interrupts.

Cheers,
Ben.

> -Scott
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev