PCI-Express root complex quirk in virtual P2P bridge

PCI-Express root complex quirk in virtual P2P bridge

[Kumar Gala]

I was hoping to get some guidance on how to handle a quirk in how the  
virtual P2P bridge works on some embedded PowerPC PCI-Express root  
complex controllers.  In the controllers I'm dealing with when we  
change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config  
cycles to the controller itself becomes effected.  The controller  
only sends config cycles internally if the bus # in the config cycle  
matches the PCI_PRIMARY_BUS.  We end up going from being 0 to 3 in  
the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we  
are no longer able to send internal config cycles.

What we need is that either a quirk or pcibios code needs to get call  
right after we set PCI_PRIMARY_BUS so we can fixup the bus number  
relationship.  I was wondering if anyone had suggestions on how best  
to handle this.

thanks

- k

Re: PCI-Express root complex quirk in virtual P2P bridge

[David Miller]

From: Kumar Gala <galak@kernel.crashing.org>
Date: Wed, 13 Jun 2007 01:26:33 -0500

> I was hoping to get some guidance on how to handle a quirk in how the  
> virtual P2P bridge works on some embedded PowerPC PCI-Express root  
> complex controllers.  In the controllers I'm dealing with when we  
> change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config  
> cycles to the controller itself becomes effected.  The controller  
> only sends config cycles internally if the bus # in the config cycle  
> matches the PCI_PRIMARY_BUS.  We end up going from being 0 to 3 in  
> the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we  
> are no longer able to send internal config cycles.
> 
> What we need is that either a quirk or pcibios code needs to get call  
> right after we set PCI_PRIMARY_BUS so we can fixup the bus number  
> relationship.  I was wondering if anyone had suggestions on how best  
> to handle this.

I would suggest building the PCI device tree using the OF device tree.
64-bit PowerPC does this already, perhaps you can use some of the
existing code for your case too.

Sparc64 does as 64-bit PowerPC does.

I can't even program the PCI-E root controller in PCI config space on
sparc64 Niagara systems, so I just virtualize it.

Re: PCI-Express root complex quirk in virtual P2P bridge

[Kumar Gala]

On Jun 13, 2007, at 1:40 AM, David Miller wrote:

> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Wed, 13 Jun 2007 01:26:33 -0500
>
>> I was hoping to get some guidance on how to handle a quirk in how the
>> virtual P2P bridge works on some embedded PowerPC PCI-Express root
>> complex controllers.  In the controllers I'm dealing with when we
>> change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config
>> cycles to the controller itself becomes effected.  The controller
>> only sends config cycles internally if the bus # in the config cycle
>> matches the PCI_PRIMARY_BUS.  We end up going from being 0 to 3 in
>> the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we
>> are no longer able to send internal config cycles.
>>
>> What we need is that either a quirk or pcibios code needs to get call
>> right after we set PCI_PRIMARY_BUS so we can fixup the bus number
>> relationship.  I was wondering if anyone had suggestions on how best
>> to handle this.
>
> I would suggest building the PCI device tree using the OF device tree.
> 64-bit PowerPC does this already, perhaps you can use some of the
> existing code for your case too.

Unfortunately that isn't really an option, since on the embedded side  
we allow the device tree to be much simpler.  For example, we dont  
require the firmware to produce a full PCI device tree and populate  
the device tree with it.  A lot of embedded PPCs use linux as the pci  
bios.

> Sparc64 does as 64-bit PowerPC does.

Both of these platforms do it because their OF implementations are  
more complete than anything we'd see on the embedded side.

> I can't even program the PCI-E root controller in PCI config space on
> sparc64 Niagara systems, so I just virtualize it.

- k