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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).