From: "Mark A. Greer" <mgreer@mvista.com>
To: linuxppc-dev@lists.linuxppc.org
Subject: Early PCI auto-configuration
Date: Thu, 26 Oct 2000 15:46:35 -0700 [thread overview]
Message-ID: <39F8B44B.7980796@mvista.com> (raw)
[The discussion below is based on the latest fsmlabs 5005 repository
code]
Disclaimer: I'm fairly new to linux PPC so my apologies if this has been
discussed before.
My problem: The firmware on a couple platform I need to support do
absolutely _no_ PCI device initialization.
To make things work for these boards in the current setup, I need to use
one of the pcibios_fixup() or pcibios_fixup_bus() hooks to walk the
entire bus tree, setup the devices (including bridges), and sort out all
the stuff that's already been put in the the "resource" entries--or am I
missing something??
I would prefer to run a "pci auto-configurator" that sets up all the
devices and bridges before pci_init() runs so I don't waste as much time
reading bad info and they trying to fix it all up later. The "fixup"
routines can still be used for minor tweaks and interrupt routing, etc.
I was thinking of doing it this ways...
>From the xxx_find_bridges() routine, call "pci_auto_scan_hose()" which
walks the entire bus hierarchy under each "hose" sorting out resources,
enumerating the buses, setting up bridges and their bounds, etc.
pci_init() will run some time later and pick up reasonable BAR values.
To make this work, I will add 4 fields to the pci_controller [or "hose"]
structure that have the upper and lower bounds for PCI I/O and memory
space for each hose. This is what the auto-configurator will use to
constrain his resource allocations.
Also, while I'm at it, add 2 more fields to pci_controller, one an array
of 32*8 int's that contian the devfn value of any devfn's that the
auto-configurator should skip. The other is the number of valid entries
in the array. This is useful--to me anyway--because I want the
auto-configurator to skip the host bridge itself. Also, on some
platforms, the host bridge also has an external IDSEL line that is
hooked up to a PCI address line. Some bridges can not handle having
themselves selected so that device needs to be skipped.
Any comments? Is there a better way? Am I getting carried away?
Thanks,
Mark
--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ 85282
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2000-10-26 22:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-26 22:46 Mark A. Greer [this message]
2000-10-26 23:26 ` Early PCI auto-configuration Benjamin Herrenschmidt
2000-10-27 2:23 ` Matt Porter
2000-10-27 3:01 ` Frank Rowand
2000-10-27 17:24 ` Geert Uytterhoeven
2000-10-27 19:06 ` Mark A. Greer
2000-11-16 23:05 ` header file location Frank Rowand
2000-11-17 6:52 ` Geert Uytterhoeven
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=39F8B44B.7980796@mvista.com \
--to=mgreer@mvista.com \
--cc=linuxppc-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.