From: Paul Mackerras <paulus@linuxcare•com.au>
To: Linux/PowerPC Devel List <linuxppc-dev@lists•linuxppc.org>
Subject: Re: dual head r128
Date: Tue, 17 Oct 2000 11:12:15 +1100 (EST) [thread overview]
Message-ID: <14827.39263.212734.807452@argo.linuxcare.com.au> (raw)
In-Reply-To: <Pine.HPX.4.10.10010121719150.16113-100000@gra-ux1.iram.es>
Gabriel Paubert writes:
> On Thu, 12 Oct 2000, Benjamin Herrenschmidt wrote:
>
> > On the kernel side, one of the PCI IO busses will be mapped to ISA. What
> > I'll do is basically to change the kernel inb/outb functions to do
> > something like
> >
> > if (addr < 64k)
> > do_io(isa_io_base + addr)
> > else
> > do_io(addr)
>
> No please, is there anybody bloat-conscious on this damned list ? Burying
> more and more code inside each {in,out}[bwl] is not the solution.
I agree that doing that in inb/outb is a bad idea.
> Just define a macro ISA_PORT or something like this and update the kernel
> to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
You mean everywhere in all the generic code? I confidently predict
that that wouldn't be accepted into the official kernel sources (and
nor should it be accepted).
> Advantages:
> - no iobase added in the PCI case: add iobase to all the
> pci_resource_start and the driver code shrinks. Have you ever counted
> the lwz instructions to access iobase, I have seen sequences where it
> represented 1/4 to 1/3 of the instructions!
I think iobase should be a constant, and we should set up our virt ->
phys mapping to do anything fancy that we might need.
> PCI I/O resources will have to be kernel virtual, physical is impossible
> with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
> from 2 to 3 Gb physical and the first thing to do is to reallocate devices
> which use it since most firmware use it too liberally, like one device
> every ... 256Mb). There are other and better ways to increase user
> available virtual space, however. And anyway I don't want any stinking add
> in each in/out macro.
Adding a constant is fine, that's just one instruction. I think you
need to stop and look at the relative speeds of an I/O access
(hundreds of nanoseconds, if not microseconds) with the speed of a few
instructions or even a cacheable load. In any case, I/O accesses are
actually very infrequent (if you don't believe me, measure it), unless
you're doing PIO to a high-bandwidth device, in which case it should
be using DMA.
> > Unfortunately, there's no simple way to allow two busses to have the
> > legacy IOs. That means on UniN machines that they'll be available either
> > on the AGP bus, or the external PCI bus, but not both.
>
> Indeed, this is too awkward (is tere no way to redirect only the VGA
> part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
> I've not yet used a single machine with AGP so I'm ignorant).
Could someone fill me in on why we need legacy I/O to the AGP bus?
Paul.
--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare•com.au, http://www.linuxcare.com.au/
Linuxcare. Support for the revolution.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-10-17 0:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-11 18:17 dual head r128 Josh Huber
2000-10-11 18:43 ` Michel Dänzer
2000-10-11 18:52 ` Josh Huber
2000-10-11 19:04 ` Tom Rini
2000-10-11 19:09 ` Michel Dänzer
2000-10-11 19:26 ` Josh Huber
2000-10-11 22:48 ` Michel Dänzer
2000-10-13 17:16 ` Josh Huber
2000-10-12 13:09 ` Kostas Gewrgiou
2000-10-12 15:13 ` Benjamin Herrenschmidt
2000-10-12 15:49 ` Gabriel Paubert
2000-10-12 16:40 ` David Edelsohn
2000-10-17 0:12 ` Paul Mackerras [this message]
2000-10-17 5:56 ` Michel Lanners
2000-10-17 10:41 ` Benjamin Herrenschmidt
2000-10-17 13:45 ` Geert Uytterhoeven
2000-10-17 17:17 ` Benjamin Herrenschmidt
2000-10-12 16:44 ` Kostas Gewrgiou
2000-10-11 21:01 ` Gabriel Paubert
-- strict thread matches above, loose matches on Subject: below --
2000-10-12 13:41 Hendricks, Kevin
2000-10-12 14:10 ` Kostas Gewrgiou
2000-10-12 14:30 Hendricks, Kevin
2000-10-12 16:11 ` Kostas Gewrgiou
2000-10-12 17:22 ` Michel Dänzer
2000-10-12 17:44 ` Kostas Gewrgiou
2000-10-12 21:25 ` Michel Dänzer
2000-10-13 15:26 ` Kostas Gewrgiou
2000-10-13 16:21 ` Geert Uytterhoeven
2000-10-12 16:25 Hendricks, Kevin
[not found] <200010121619.TAA27476@ns0.imbc.gr>
2000-10-12 17:08 ` Kostas Gewrgiou
[not found] <19340906102959.14429@192.168.1.2>
2000-10-12 17:57 ` Gabriel Paubert
[not found] <Pine.LNX.4.10.10010132302530.381-100000@cassiopeia.home>
2000-10-13 21:36 ` Benjamin Herrenschmidt
2000-10-13 21:47 ` Michel Lanners
2000-10-14 10:13 ` Benjamin Herrenschmidt
2000-10-14 10:21 ` Geert Uytterhoeven
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=14827.39263.212734.807452@argo.linuxcare.com.au \
--to=paulus@linuxcare$(echo .)com.au \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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