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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
