I'm just catching up with this thread and I'm
not sure which problem it is that we're trying
to solve here. Isn't it true that the various
pci_ops routines are passed a pci_dev from which
they can extract pci_dev->pci_bus->number and
decide which bus is meant from that? Or does
that constitute a namespace (or number-space)
collision? Aha - yes it might - each "node" in
a PCI bus "tree" has its own bus number, right?
So pci_dev->pci_bus->number is only intended to
be meaningful within a given tree and each tree
is (should be) its own domain...
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
The bus number refers to the segment of PCI between bridges (host
PCI-PCI, or other) or attached to a single bridge; multiple host
bridges are referenced although I have never tried it. So, from
your host bridge, for example the embedded MPC107 in an '8240, there
are four Ethernet devices, an IDE interface, and a PCI-PCI bridge,
and then there are two Fibre Channel devices attached to the PCI-
PCI bridge. There will be two pci_bus structures, one for the PCI
bus from the host bridge to the PCI-PCI bridge, which should be bus
number 0, and another for the PCI bus on the "other" side of the
PCI-PCI bridge, which should be number 1. All the Ethernet devices'
AND the PCI-PCI bridge's pci_dev structures will point to the
HOST BRIDGE pci_bus structure; the Fibre Channel devices will point
to a pci_bus structure associated with the PCI-PCI bridge.
Even if you have non-standard bridges, this works; I have used an
Intel 21554 in configurations where a card is sometimes the system
controller (assigner of PCI addresses for all of the other devices)
and sometimes not.
The routines for reading/writing configuration space, assigning
addresses, AND converting PCI addresses <-> CPU addresses have to
encapsulate the "magic" knowledge of the hardware configuration
to allow drivers to be portable across different implementations.
If you have hardware with offsets, then encode that in the bus_to_virt
conversion routine. Set up tables in
arch/ppc/kernel/<your_implementation>.c,
if you have to; even with multiple host bridges, there should be NO
duplicated PCI addresses on different PCI busses, even though the
spec' allows it. We HAVE the source; we CONTROL the address assignments;
even if you have offsets (as the 21554 does), don't replicate addresses.
Use only part of the available address space on each bus and use some
of the upper bits as tags so bus_to_virt, etc. can uniquely identify the
bus from the address and provide the correct response.
mod+linuxppc-embedded@MissionCriticalLinux.com wrote:
I'm just catching up with this thread and I'm
not sure which problem it is that we're trying
to solve here. Isn't it true that the various
pci_ops routines are passed a pci_dev from which
they can extract pci_dev->pci_bus->number and
decide which bus is meant from that? Or does
that constitute a namespace (or number-space)
collision? Aha - yes it might - each "node" in
a PCI bus "tree" has its own bus number, right?
So pci_dev->pci_bus->number is only intended to
be meaningful within a given tree and each tree
is (should be) its own domain...
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan Taylor wrote:
The bus number refers to the segment of PCI between bridges (host
PCI-PCI, or other) or attached to a single bridge; multiple host
bridges are referenced although I have never tried it. So, from
your host bridge, for example the embedded MPC107 in an '8240, there
are four Ethernet devices, an IDE interface, and a PCI-PCI bridge,
and then there are two Fibre Channel devices attached to the PCI-
PCI bridge. There will be two pci_bus structures, one for the PCI
bus from the host bridge to the PCI-PCI bridge, which should be bus
number 0, and another for the PCI bus on the "other" side of the
PCI-PCI bridge, which should be number 1. All the Ethernet devices'
AND the PCI-PCI bridge's pci_dev structures will point to the
HOST BRIDGE pci_bus structure; the Fibre Channel devices will point
to a pci_bus structure associated with the PCI-PCI bridge.
All of this is correct but it doesn't address the actual issue.
Background:
When generating a config addr on a PCI bus, you encode the bus number of the
target bus. If the encoded bus number matches the pci bus immediately below
the bridge, a Type 0 cycle is generated on that PCI bus; if not the same, a
Type 1 cycle is generated and should be claimed by the appropriate bridge on
that pci bus. So, if you want to talk to a device on the PCI bus directly
below the host bridge, you must have the same bus number encoded in the config
addr that the bridge thinks that bus is (make sense?).
Up until now, host bridges with 2 pci buses (that's 2 "hoses" in linuxppc
nomenclature) hanging off them have allowed the s/w to set the bus number of
the second hose. This lets us set up the second hose to "think" its pci bus
is the same bus number as we use up in linuxppc-land so linuxppc pci bus
number matches the physical bus numbering of the hoses.
With the gt64260, BOTH hoses are considered PCI bus 0 so when generating the
config addr that gets passed to the bridge for the second hose, you have to
subtract out the number of buses on the first hose. That's the problem being
solved here.
Now that I've said all that, I think I've just found a way to set the bus
number of the second hose so, if it works, all of this becomes moot.
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/