public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed

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$(echo .)com \
    --cc=linuxppc-dev@lists$(echo .)linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox