Benjamin Herrenschmidt wrote:
On Wed, 2010-01-13 at 10:18 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2010-01-12 at 15:09 +0100, Stef van Os wrote:
This patch adds type 1 PCI transactions to 4xx PCI code, enabling the
discovery of
devices behind a PCI bridge.
Your patch appears word wrapped and whitespace damaged...
I'll fix it up manually this time around but please check your mailer
setup :-)
Allright, it's not quite that.
I've looked at my docs, and it looks like older parts such as the 440EP
do -not- take the config type in the low bit.
More interestingly, they only generate config 0 cycles if you pass a bus
number of 0 :-)
So we'll need do do something a little bit different here. We probably
need to indicate in the device-tree what kind of SoC we have (whether
it supports the explicit bit to choose between type 0 and type 1 or
not).
If not, we should then set the "self_busno" field of the bridge to 0,
causing indirect_pci to always use bus number 0 when trying to talk
to the bus segment behind the bridge, whatever the linux bus number
for it actually is.
Now, we need to make a precise list here of what SoC uses what. 460xx
seem to all support the explicit bit. 440EP doesn't. What else ?
Somebody from AMCC can dbl check that ?
I've checked what platforms take configuration type in the lower bit:
405XX - no
440EP - no
440GR - no
440EPx/440GRx - no
440GP - yes
440GX - yes
440SP - yes
440SPe - yes
460XX - yes
The distinction between these groups is pretty clear in the device trees.
The members of the first group all have "ibm,plb-pci" property, and all
members of second group have "ibm,plb-pcix" property.
So only ppc4xx_probe_pcix_bridge() routine should be fixed.
Felix.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
