Early PCI auto-configuration

Early PCI auto-configuration

[Mark A. Greer]

[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/

Re: Early PCI auto-configuration

[Benjamin Herrenschmidt]

>
>[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/

Re: Early PCI auto-configuration

[Matt Porter]

On Fri, Oct 27, 2000 at 01:26:59AM +0200, Benjamin Herrenschmidt wrote:
> >My problem:  The firmware on a couple platform I need to support do
> >absolutely _no_ PCI device initialization.

<snip>

> 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.

This stuff is the key.  After a good read of alpha's usage of the
setup-res.c, setup-irq.c, and setup-bus.c code I'm really impressed
with how they are using it to accomplish what Mark has been doing
with an autoconfigurator that runs before the first busscan (in 2.2
that was the best solution).

Tracing through arch/alpha/kernel/pci.c around the call to to
pci_assign_unassigned_resources() is a good way to get a feel of
how the generic resource handling code can be used to accomplish
autoconfiguration in a post bus scan way.  It's not as pretty
as doing it right the first time but the code is already there and
easy to hook in to...see following snippet:

	[loop to scan all pci controllers]
        pcibios_size_bridges();
        pci_assign_unassigned_resources();
        pci_fixup_irqs(alpha_mv.pci_swizzle, alpha_mv.pci_map_irq);
        pci_set_bus_ranges();

After doing some PCI bus swizzle routines for the embedded Motorola
boards for 2.2 (prep_pci.c), it's nice to see a generic swizzle
routine that can be passed an irq map to do the dirty work in the
new resources framework.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Early PCI auto-configuration

[Frank Rowand]

Benjamin Herrenschmidt wrote:
>
> >
> >[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.

< 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 <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Early PCI auto-configuration

[Geert Uytterhoeven]

On Fri, 27 Oct 2000, Benjamin Herrenschmidt wrote:
> >[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.


> 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/

Re: Early PCI auto-configuration

[Mark A. Greer]

Geert Uytterhoeven wrote:

> <cut>
>
> > 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/

header file location

[Frank Rowand]

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/

Thanks,

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: header file location

[Geert Uytterhoeven]

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/