linux-mips
[Top] [All Lists]

Re: Proposal: non-PC ISA bus support

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: Proposal: non-PC ISA bus support
From: Benjamin Herrenschmidt <bh40@calva.net>
Date: Tue, 20 Jun 2000 15:02:38 +0200
Cc: Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>, Linux/MIPS Development <linux@cthulhu.engr.sgi.com>, Linux kernel <linux-kernel@vger.rutgers.edu>
In-reply-to: <Pine.GSO.4.10.10006201438290.8592-100000@dandelion.sonytel.be>
References: <Pine.GSO.4.10.10006201438290.8592-100000@dandelion.sonytel.be>
Sender: owner-linux-mips@oss.sgi.com
On Tue, Jun 20, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>Concatenating the I/O spaces seems like the best solution to me as well.

Would work if the ranges you are passing via /proc/bus/isa/xxxx are
kernel virtual addresses and not physical addresses (I didn't check if
this is the case).

>Hmmm... If you can live with only one video card with legacy support, what
>about a kernel option to specify which of the 3 busses will be the first?

I've been thinking about it. That would be a solution. Also, the fbdev's
we use for cards in the AGP slot (ATI Rage 128 for now) can handle this
fine, and XFree has already been more or less hacked when to handle it
too when running on top of fbdev.

>Else, we'll have to work around this in XFree86.

Well, we'll have to find a workaround one way or another. The only
solution I can see for this problem is a way for each individual card
driver to "ask" the kernel for an iobase which is specific to this card,
given in parameter as much infos as the driver can regarding the device
(like the pci_dev for a pci device). The kernel would then be able to
locate the device in the OF tree, walk the tree up to the nearest brige
and figure out the correct IO range. (It already does something similar
for config space accesses since we have the same problem of 3 different
config space access registers). For in-kernel drivers, this can be done
at the PCI fixup level provided that the driver uses the io resources
given to it "as is", but exposing this to userland may require more than
a /proc entry.

Ben.


<Prev in Thread] Current Thread [Next in Thread>