[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/
[The discussion below is based on the latest fsmlabs 5005 repository
code]
You mean linuxppc_2_5, I guess ?
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??
Well, if you set pci_assign_all_busses to 1 before pci_init() (do it
during your setup_arch, when creating your hose), the kernel will at
least setup bus numbers for you.
You still have to handle allocation of device resources. The current code
has no per-hose resources that would allow the common PPC PCI code to
then assign resources to devices on the bus. So you need your own at
fixup time.
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.
Well, the kernel can behave quite well with unconfigured devices as long
as your implementation of pcibios_enable_device() configures it. Of
course, you need to configure the interrupt controller and other such
vital devices early.
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.
There is no reason to do it at this point since the pci_scan_bus() can
assign bus numbers and have no trouble with wrong resources.
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.
That's what I call per-hose resource. That's I think the good way, but
_please_, if you implement that, support multiple (disconiuous) resources
per hose ;) On PowerMac, for example, we have a theorical limit of
something like 28 decoded memory ranges :) In real life, I don't think
we'll have more than 2 or 3 of them on a given bus however.
Then, you could implement your autoconfigurator (triggered via a global
that defaults to 0, something like pci_assign_all_devices) just after the
pci_scan_bus() pass.
But if I understand Geert code correctly, except for IDE devices & VGA
cards, the pcibios_assign_resources() function will assign bases
addresses to unassigned devices. This is done by the call to
pcibios_assign_resources(), and works if your bus resources & ranges have
been setup properly.
You may still need some fixup around, I'm really curious about what is
needed, and if the exception done for IDE & VGA cannot be changed to be
special "rules" of the PPC common pci code that would be enabled by
setup_arch().
You may also want to look at pci_assign_unassigned_resources() (in
drivers/pci/setup-res.c) and friends. They do things a bit differently,
but it might match more closely what you want.
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.
That's a good idea to handle the special cases discussed above, like
skipping VGA & IDE on some machines.
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.
Please, keep me in contact, I'm really interested in what you end up doing.
Regards,
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Benjamin Herrenschmidt wrote:
quoted
[The discussion below is based on the latest fsmlabs 5005 repository
code]
You mean linuxppc_2_5, I guess ?
quoted
My problem: The firmware on a couple platform I need to support do
absolutely _no_ PCI device initialization.
< stuff deleted >
You may also want to look at pci_assign_unassigned_resources() (in
drivers/pci/setup-res.c) and friends. They do things a bit differently,
but it might match more closely what you want.
Note that pci_assign_unassigned_resources() gets called by the Alpha, MIPS,
and ARM kernels for this purpose, if I understand correctly...
--
Frank Rowand [off-list ref]
MontaVista Software, Inc
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, 27 Oct 2000, Benjamin Herrenschmidt wrote:
quoted
[The discussion below is based on the latest fsmlabs 5005 repository
code]
You mean linuxppc_2_5, I guess ?
quoted
My problem: The firmware on a couple platform I need to support do
absolutely _no_ PCI device initialization.
But if I understand Geert code correctly, except for IDE devices & VGA
I copied that code from ia32, with some minor modifications to make it work
with the Open Firmware on my LongTrail.
cards, the pcibios_assign_resources() function will assign bases
addresses to unassigned devices. This is done by the call to
pcibios_assign_resources(), and works if your bus resources & ranges have
been setup properly.
Yep. If you set up the bus resources correctly, that code will assign all
unassigned resources automatically (and reassign conflicting resources) from
the ranges specified by the bus resources.
BTW, before I did this on PPC, I played with PCI resource assignment on a MIPS
board, where the firmware didn't do any PCI assignments (except for Ethernet,
to boot images using TFTP), which is exactly what you want. For reference, that
code is in arch/mips/ddb5074/pci.c.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Geert Uytterhoeven wrote:
<cut>
quoted
cards, the pcibios_assign_resources() function will assign bases
addresses to unassigned devices. This is done by the call to
pcibios_assign_resources(), and works if your bus resources & ranges have
been setup properly.
Yep. If you set up the bus resources correctly, that code will assign all
unassigned resources automatically (and reassign conflicting resources) from
the ranges specified by the bus resources.
BTW, before I did this on PPC, I played with PCI resource assignment on a MIPS
board, where the firmware didn't do any PCI assignments (except for Ethernet,
to boot images using TFTP), which is exactly what you want. For reference, that
code is in arch/mips/ddb5074/pci.c.
Geert, Ben, Matt,
Thanks for the feedback. I've looked through much of the code you guys pointed
out and it does look like it will do what I want. I'll hook it up and see how it
goes.
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 16 Nov 2000, Frank Rowand wrote:
Is there any documentation of how to decide where to put header files. I especially
am trying to understand the distinction between include/asm-ppc/ and arch/ppc/kernel/
If the includes are used in arch/ppc/kernel/ only, put them there. If they are
needed elsewehere as well (arch/ppc/mm/, drivers/..., userspace), put them in
include/asm-ppc/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/