pci node question

[Kumar Gala]

On Apr 20, 2012, at 2:04 PM, Scott Wood wrote:

> On 04/20/2012 01:53 PM, Kumar Gala wrote:
>> 
>> On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
>> 
>>> There was refactoring change a while back that moved 
>>> the interrupt map down into the virtual pci bridge.
>>> 
>>> example: 
>>> 42 /* controller at 0x200000 */
>>> 43 &pci0 {
>>> 44         compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
>>> 45         device_type = "pci";
>>> 46         #size-cells = <2>;
>>> 47         #address-cells = <3>;
>>> 48         bus-range = <0x0 0xff>;
>>> 49         clock-frequency = <33333333>;
>>> 50         interrupts = <16 2 1 15>;
>>> 51         pcie at 0 {
>>> 52                 reg = <0 0 0 0 0>;
>>> 53                 #interrupt-cells = <1>;
>>> 54                 #size-cells = <2>;
>>> 55                 #address-cells = <3>;
>>> 56                 device_type = "pci";
>>> 57                 interrupts = <16 2 1 15>;
>>> 58                 interrupt-map-mask = <0xf800 0 0 7>;
>>> 59                 interrupt-map = <
>>> 60                         /* IDSEL 0x0 */
>>> 61                         0000 0 0 1 &mpic 40 1 0 0
>>> 62                         0000 0 0 2 &mpic 1 1 0 0
>>> 63                         0000 0 0 3 &mpic 2 1 0 0
>>> 64                         0000 0 0 4 &mpic 3 1 0 0
>>> 65                         >;
>>> 66         };
>>> 67 };
>>> 
>>> Why was the interrupt-map moved here?
>> 
>> Its been a while, but I think i moved it down because of which node is used for interrupt handling in linux.
> 
> That's not supposed to be how device tree bindings are determined.
> 
> 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).
> 
> What does this node represent in the first place?  Is there really a
> PCI-to-PCI bridge?  Are all other PCI devices underneath it?

PCIe has this concept of a "virtual" bridge between the root-comples, so that is what the node represents.  Its always been a bit confusing to me as its not 100% standardized by PCI sig.

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.

> 
>>> Why is there a zeroed out reg property: reg = <0 0 0 0 0> ??
>> 
>> scratching my head, what happens if you remove it?
> 
> Sigh.

:)

- k