Re: Proposal: non-PC ISA bus support

Re: Proposal: non-PC ISA bus support

[Benjamin Herrenschmidt]

On Tue, Jun 20, 2000, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
wrote:


> 1. Provide /proc/bus/isa/map, which contains the ISA I/O and memory space
>    mappings on machines where these are memory mapped.
>
>    Example (on PPC CHRP LongTrail):
>
>	callisto$ cat /proc/bus/isa/map
>	f8000000	01000000	IO
>	f7000000	01000000	MEM
>	callisto$

Looks fine except for one thing: How can we handle weird HW (like Apple
Uni-N bridge) that has actually 3 different IO spaces at different
locations (all of them beeing childs of the same PCI bus).
This is more or less related since the ISA iospace can be considered as a
subset of the PCI IO space. The problem is generic (it happens with both
"pure" PCI drivers doing IOs and ISA drivers doing IOs). The problem
exist for both the kernel and userland apps like XFree wanting to do PCI
or ISA IOs. The kernel has a built-in IO-base, your patch would expose it
to userland fixing part of the problem for XFree (so userland don't have
to probe for zillion different bridges) but wouldn't solve the problem of
multiple busses.

Paul suggested mapping them one after each other in a single contiguous
region (with the appropriate fixup in the kernel PCI io resources) but
this can work only for PCI IOs (drivers using the io resource base).
Drivers hard-coding legacy IO addresses will still not work (except if
they are on the first bus).

We still can decide (and that's what I currently do in the kernel) that
IO space is only supported on one of those 3 busses (the one on which the
external PCI is). This prevents however use of IOs on the AGP slot, which
is a problem for things like XFree who may try to use VGA addresses on
the card.

I still don't have a clue about a good solution to this issue. Apple
solves it in their kernel by having an object oriented bus structure,
each device asking for mappings to their parent bridge, based on the
device tree and independently of PCI bus numbers.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Proposal: non-PC ISA bus support

[De Schrijver Peter]

Hi,

> We still can decide (and that's what I currently do in the kernel) that
> IO space is only supported on one of those 3 busses (the one on which the
> external PCI is). This prevents however use of IOs on the AGP slot, which
> is a problem for things like XFree who may try to use VGA addresses on
> the card.
>

Is this really a problem ? I would expect AGP cards to be fully addresseable via
the I/O space assigned in the PCI IO resource base ?

Peter.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Proposal: non-PC ISA bus support

[Benjamin Herrenschmidt]

On Tue, Jun 20, 2000, De Schrijver Peter <schrijvp@rc.bel.alcatel.be> wrote:

>> We still can decide (and that's what I currently do in the kernel) that
>> IO space is only supported on one of those 3 busses (the one on which the
>> external PCI is). This prevents however use of IOs on the AGP slot, which
>> is a problem for things like XFree who may try to use VGA addresses on
>> the card.
>>
>
>Is this really a problem ? I would expect AGP cards to be fully
>addresseable via
>the I/O space assigned in the PCI IO resource base ?

But even that doesn't work. If it's a kernel driver, then we can fixup
the io resources passed by the new kernel resources mecanism to handle
the IO base of this specific card. But this won't for userland.

I mean, if you read the PCI IO resource base from the card's config
space, then you have an IO address on which you need to add an iobase
(the base at which the IO bus is mapped). The problem is how to figure
out this IO base, especially since the machine has several IO busses at
different addresses, but all of them on the same PCI bus number (it's
actually 3 separate busses with the same bus number).

The kernel can figure this out from the dev_fn since there's fortunately
no overlap of dev_fn's between those busses. But how to translate this to
userland ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Proposal: non-PC ISA bus support

[Michel Lanners]

Hi all,

On  20 Jun, this message from Benjamin Herrenschmidt echoed through cyberspace:
> We still can decide (and that's what I currently do in the kernel) that
> IO space is only supported on one of those 3 busses (the one on which the
> external PCI is). This prevents however use of IOs on the AGP slot,

... and multiple host bridges, like on the 9x00 (bad, two separate buses
    à 3 slots) and 7x00/8x00 (no problem, second (fixed, video
    subsys) bus doesn't have IO devices).

struct pci_dev has void *sysdata. Can we use that for something
reasonable here? Like additional info (iobase per device, set by fixup
code)?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/