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
From: Kumar Gala <[email protected]>
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.
On Jun 13, 2007, at 1:40 AM, David Miller wrote:
> From: Kumar Gala <[email protected]>
> 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