Note to linux-kenrel readers: This discussion is the Nth attempt to find
a solution to handle both legacy IOs and PCI IOs on machines with several
IO busses memory mapped at different locations in the CPU space.
>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.
Well, that is pretty small overhead, and probably ridiculous compared to
the overhead of the IO itself. Most fast devices use MMIO anyway.
The problem is that whatever solution someone propose, there is _always_
somebody to reject it.
>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
>don't do it you'll get a nice panic so you'll find all the places quite
>fast.
That basically mean making different macros for ISA in/out and PCI in/
out. I've proposed this several time, but it requires changes to the
common code, and all I got when talking about this was flames from x86 people.
>Drawbacks ?
Take the time to make this fit into some x86 people head. Also, I need
something that can be ported quickly to 2.4. I'm afraid even if we make
everybody agree to it, it will be delayed to 2.5.
Linus: Would you accept this change now ?
#define ISA_PORT(n) (n)
And change to _all_ drivers doing legacy IOs to use that in their in/out
macros ?
I still prefer making separate macros for legacy IOs (isa_in/isa_out) and
for PCI IOs (in/out), or the opposite if you prefer (in/out for isa and
pci_in/pci_out for PCI).
On x86, they would resolve to the same thing, while on our platforms,
they could be handled differently.
>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.
Well, in 2.4 we can easily reassign PCI IOs if we configure the bridge
with proper resources. If all goes well, my new PCI code should handle
that fine (should be ready this week-end).
>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).
No, most bridges used on macs can't do that. In fact, AFAIK, it's not
possible to access the ISA memory space neither on those machines (on
UniN, I can't generate memory cycles at lower address than 0x80000000).
My "pet" solution would be to have all legacy drivers request an IO base
this way
base = isa_get_IO_base(legacy_addr);
The isa_get_IO_base function could then be "tweaked" to recognize known
legacy addresses and return different bases. (There might still be
problems with VGA vs. parallell, I don't know x86 world well enough to be
sure).
Ben.
------------------ RFC822 Header Follows ------------------
From: Benjamin Herrenschmidt <bh40@calva.net>
To: Gabriel Paubert <paubert@iram.es>, Linux/PowerPC Devel List
<linuxppc-dev@lists.linuxppc.org>, Linus Torvalds <torvalds@transmeta.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: dual head r128
Date: Thu, 12 Oct 2000 18:58:15 +0200
Message-Id: <19340906102959.14429@192.168.1.2>
In-Reply-To: <Pine.HPX.4.10.10010121719150.16113-100000@gra-ux1.iram.es>
References: <Pine.HPX.4.10.10010121719150.16113-100000@gra-ux1.iram.es>
X-Mailer: CTM PowerMail 3.0.5 <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
-----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:23 EST