From: Dan Taylor <danieltaylor@we.mediaone.net>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Adding 'bus_offset' to pci_controller
Date: Thu, 27 Sep 2001 12:37:44 -0700 [thread overview]
Message-ID: <3BB38008.39A3F149@we.mediaone.net> (raw)
In-Reply-To: 200109271310.JAA20256@missioncriticallinux.com
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/
next prev parent reply other threads:[~2001-09-27 19:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3BB24A6B.BADCF16E@mvista.com>
[not found] ` <15282.23932.770208.130313@cargo.ozlabs.ibm.com>
[not found] ` <3BB2639D.A44BCA16@mvista.com>
2001-09-26 23:29 ` Adding 'bus_offset' to pci_controller Mark A. Greer
2001-09-27 0:59 ` Paul Mackerras
2001-09-26 21:54 ` Matt Porter
2001-09-27 13:10 ` mod+linuxppc-embedded
2001-09-27 19:37 ` Dan Taylor [this message]
2001-09-27 21:42 ` Mark A. Greer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BB38008.39A3F149@we.mediaone.net \
--to=danieltaylor@we.mediaone.net \
--cc=danieltaylor@acm.org \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).