Re: pci node question

[Scott Wood <scottwood@freescale.com>]

On 04/20/2012 03:37 PM, Kumar Gala wrote:
> 
> 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@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,

Between the root complex and whatever's plugged in?

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

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

Is there an actual PCIe-to-PCIe bridge that shows up in the root
complex's config space (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?

> 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?

-Scott