From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "David S. Miller" <davem@redhat.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Going beyond 256 PCI buses
Date: Thu, 14 Jun 2001 23:57:09 +0200 [thread overview]
Message-ID: <20010614215709.23875@smtp.wanadoo.fr> (raw)
In-Reply-To: <15145.12584.339783.786454@pizda.ninka.net>
In-Reply-To: <15145.12584.339783.786454@pizda.ninka.net>
>It really isn't needed, and I understand why Linus didn't like the
>idea either. Because you can encode the bus etc. info into the
>resource addresses themselves.
>
>On sparc64 we just so happen to stick raw physical addresses into the
>resources, but that is just one way of implementing it.
That would be fine for PIO on PCI, but still is an issue for
VGA-like devices that need to issue some "legacy" cycles on
a given domain. Currently, on PPC, inx/outx will only go to
one bus (arbitrarily choosen during boot) because of that,
meaning that we can't have 2 VGA cards on 2 different domains
That's why I'd love to see a review of the "legacy" (ISA) stuff
in general. I understand that can require a bit of updating of
a lot of legacy drivers to do the proper ioremap's, but that would
help a lot, including some weird embedded archs which love using
those cheap 16 bits devices on all sorts of custom busses. In
those case, only the probe part will have to be hacked since the
drivers will all cleanly use a "base" obtained from that probe-time
ioremap before doing inx/outx.
I'd be happy to help bringing drivers up-to-date (however, I don't
have an x86 box to test with) once we agree on the way do go.
Ben.
next prev parent reply other threads:[~2001-06-14 21:58 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-13 10:02 Going beyond 256 PCI buses Tom Gall
2001-06-13 17:17 ` Albert D. Cahalan
2001-06-13 18:29 ` Tom Gall
2001-06-14 14:14 ` Jeff Garzik
2001-06-14 14:24 ` David S. Miller
2001-06-14 14:32 ` Jeff Garzik
2001-06-14 14:42 ` David S. Miller
2001-06-14 15:29 ` Jeff Garzik
2001-06-14 15:33 ` Jeff Garzik
2001-06-14 17:59 ` Jonathan Lundell
2001-06-14 19:03 ` David S. Miller
2001-06-14 20:50 ` Jonathan Lundell
2001-06-14 20:56 ` David S. Miller
2001-06-14 18:01 ` Albert D. Cahalan
2001-06-14 18:47 ` David S. Miller
2001-06-14 19:04 ` Albert D. Cahalan
2001-06-14 19:12 ` David S. Miller
2001-06-14 19:41 ` Jeff Garzik
2001-06-14 19:57 ` David S. Miller
2001-06-14 20:08 ` Jeff Garzik
2001-06-14 20:14 ` David S. Miller
2001-06-14 21:30 ` Benjamin Herrenschmidt
2001-06-14 21:35 ` David S. Miller
2001-06-14 21:46 ` Benjamin Herrenschmidt
2001-06-14 21:46 ` Jeff Garzik
2001-06-14 21:48 ` David S. Miller
2001-06-14 21:57 ` Benjamin Herrenschmidt [this message]
2001-06-14 22:12 ` David S. Miller
2001-06-14 22:29 ` Benjamin Herrenschmidt
2001-06-14 22:49 ` David S. Miller
2001-06-14 23:35 ` Benjamin Herrenschmidt
2001-06-14 23:35 ` VGA handling was [Re: Going beyond 256 PCI buses] James Simmons
2001-06-14 23:42 ` David S. Miller
2001-06-14 23:55 ` James Simmons
2001-06-15 15:14 ` Pavel Machek
2001-06-15 2:06 ` Albert D. Cahalan
2001-06-15 8:52 ` Matan Ziv-Av
2001-06-16 21:32 ` Going beyond 256 PCI buses Jeff Garzik
2001-06-16 23:29 ` Benjamin Herrenschmidt
2001-06-15 8:42 ` Geert Uytterhoeven
2001-06-15 15:38 ` David S. Miller
2001-06-14 15:13 ` Jonathan Lundell
2001-06-14 15:15 ` David S. Miller
2001-06-14 15:17 ` Jeff Garzik
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=20010614215709.23875@smtp.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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