From: Benjamin Herrenschmidt <bh40@calva.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
linuxppc-dev@lists.linuxppc.org, mlan@mcp.cpu.lu
Subject: Re: LongTrail PCI resource assignment
Date: Wed, 22 Mar 2000 14:15:32 +0100 [thread overview]
Message-ID: <20000322141532.028115@mailhost.mipsys.com> (raw)
In-Reply-To: <Pine.GSO.4.10.10003221130220.29557-100000@dandelion.sonytel.be>
On Wed, Mar 22, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple
>IO
>> windows, out of which IO resources need to be allocated (depends on the
>parent
>> bridge, in fact). So a single static definition doesn't do the job.
>>
>> Can't we replace this with a seed to the resource tree, defined per host
>bridge
>> in arch-specific code? On PowerMacs, there's a function that scans for
known
>> host bridges; that code could (either dynamically or based on hardcoded
>> knowledge) put the available IO window into some resource of the host
bridge
>> pci_dev struct. The tree of IO resources could then be built from there.
>
>The PCI resource allocation code allocates from the parent of the
device. So I
>think it must be possible to put bus-specific resource nodes in between the
>general io{port,mem}_resource that covers the whole address space and the
>device itself.
Well, ideally, we need the resource allocation/re-allocation mecanism to
rely on the parent resource node, regardless of it beeing a real PCI bus
or something else. This way, we can handle the Uni-N case by insterting
sort of per-bus nodes: (I only report IO ranges below since mem ranges
seems to be less of a problem)
Uni-N : IO 0xf0000000 - 0xf5ffffff (fake range covering all 3 sub-busses)
|
|-- Uni-N-sub1 : IO 0xf0000000 - 0xf000ffff
| |
| --- ATI AGP
|
|-- Uni-N-sub2 : IO 0xf2000000 - 0xf200ffff
| |
| --- (external PCI, can be a DEC PCI<->PCI bridge)
|
|-- Uni-N-sub3 : IO 0xf4000000 - 0xf400ffff
|
--- GMAC
|
--- Internal FireWire
Note that I don't think we need IOs at all on the GMAC/InternalFW bus.
The pmac specific PCI code would then create the 3 Uni-N-subX nodes. The
probing code needs to be hacked so that devices are put under the proper
sub nodes. Then, the reallocation/fixup code will re-assign IO ranges
based only on the device parent node exposed range.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-03-22 13:15 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-22 8:27 LongTrail PCI resource assignment Geert Uytterhoeven
2000-03-22 10:24 ` Michel Lanners
2000-03-22 10:43 ` Geert Uytterhoeven
2000-03-22 13:15 ` Benjamin Herrenschmidt [this message]
2000-03-23 7:41 ` Michel Lanners
2000-03-23 10:13 ` Benjamin Herrenschmidt
2000-03-23 19:22 ` Michel Lanners
2000-03-24 8:49 ` Timothy A. Seufert
2000-03-24 9:02 ` Geert Uytterhoeven
2000-03-24 9:54 ` Benjamin Herrenschmidt
2000-03-24 10:56 ` Michael Schmitz
2000-03-24 12:26 ` Geert Uytterhoeven
2000-03-24 13:36 ` Michael Schmitz
2000-03-24 13:48 ` Geert Uytterhoeven
2000-03-24 12:37 ` Geert Uytterhoeven
2000-03-24 13:27 ` Michael Schmitz
2000-03-24 13:34 ` Geert Uytterhoeven
2000-03-24 16:07 ` Michael Schmitz
2000-03-24 13:35 ` Gabriel Paubert
2000-03-24 13:48 ` Michael Schmitz
2000-03-24 14:10 ` Benjamin Herrenschmidt
2000-03-24 15:56 ` Gabriel Paubert
2000-03-24 17:40 ` Michael Schmitz
2000-03-24 17:51 ` Gabriel Paubert
2000-03-24 18:43 ` Michael Schmitz
2000-03-24 20:03 ` Gabriel Paubert
2000-03-24 21:37 ` Michael Schmitz
2000-03-25 13:35 ` Geert Uytterhoeven
2000-03-25 15:13 ` Michael Schmitz
2000-03-27 8:57 ` Michael Schmitz
2000-03-27 9:43 ` Michel Dänzer
2000-03-27 9:58 ` Michael Schmitz
2000-03-27 10:38 ` Geert Uytterhoeven
2000-03-29 20:05 ` Geert Uytterhoeven
2000-03-30 20:59 ` Michael Schmitz
2000-04-03 8:58 ` Michel Lanners
2000-04-03 18:42 ` Michael Schmitz
2000-04-04 6:01 ` Michel Lanners
2000-03-27 11:33 ` Kostas Gewrgiou
2000-03-27 11:46 ` Michael Schmitz
2000-03-27 12:04 ` Geert Uytterhoeven
2000-03-27 11:51 ` Geert Uytterhoeven
2000-03-27 11:58 ` Michael Schmitz
2000-03-27 12:04 ` Michel Dänzer
2000-03-27 11:41 ` Michel Dänzer
2000-03-27 9:50 ` Geert Uytterhoeven
2000-03-27 10:01 ` Michael Schmitz
2000-03-27 10:35 ` Geert Uytterhoeven
2000-03-27 11:34 ` Michael Schmitz
2000-03-27 11:54 ` Geert Uytterhoeven
2000-03-27 16:55 ` Michael Schmitz
2000-03-27 18:58 ` Michel Lanners
2000-03-27 20:03 ` Michael Schmitz
2000-03-27 21:03 ` Michel Lanners
2000-03-27 11:46 ` Michel Lanners
2000-03-25 14:15 ` Michel Dänzer
2000-03-25 13:28 ` Geert Uytterhoeven
2000-03-25 14:36 ` Michael Schmitz
2000-03-24 22:16 ` Michel Lanners
2000-03-24 9:43 ` Benjamin Herrenschmidt
2000-03-24 22:13 ` Michel Lanners
2000-03-24 13:12 ` Benjamin Herrenschmidt
2000-03-24 22:41 ` Michel Lanners
2000-03-22 13:18 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2000-03-24 15:42 Michel D?nzer
2000-03-24 16:30 ` Michael Schmitz
2000-03-24 17:17 ` Benjamin Herrenschmidt
2000-03-24 18:27 ` Michael Schmitz
2000-03-25 13:31 ` Geert Uytterhoeven
2000-03-25 14:28 ` Michel Dänzer
2000-03-25 14:49 ` Geert Uytterhoeven
2000-03-26 8:45 ` Michel Dänzer
2000-03-25 15:39 ` Michael Schmitz
2000-03-26 8:58 ` Michel Dänzer
2000-03-27 9:43 ` Michael Schmitz
2000-03-27 11:27 ` Michel Dänzer
[not found] <Pine.GSO.4.10.10003220927550.29557-100000@dandelion.sonytel.be>
2000-03-27 21:12 ` Martin Mares
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=20000322141532.028115@mailhost.mipsys.com \
--to=bh40@calva.net \
--cc=geert@linux-m68k.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mlan@mcp.cpu.lu \
/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.