Re: dual head r128

But you can fixup all pci_dev's so bus 0 takes 0x00000-0x0fffff, bus 1 takes
0x10000-0x1ffff, and so on. ioportremap() finds out the bus by looking at the
region.

I/O space is not limited to 64 kB on non-ia32, we can use the full size of an
unsigned long.

Legacy I/O mappings (`I have legacy lp0 on bus 0 and legacy lp1 on bus

1') can

be sorted out in ioportremap() as well.

Ok, If I follow you correctly, that mean that if we have, for example,
bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
in this range, the address + bus_io_base - 0x10000. At least on Macs,
AFAIK, we have only 64k or 128k of IOs available.

I still need to think about this, I'll leave the code in bk _2_5 as it is
now (which is the good old IO_BASE) and leave those IO changes for after
I'm finished with per-hose resources.

Ben.

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

Ok, If I follow you correctly, that mean that if we have, for example,
bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
in this range, the address + bus_io_base - 0x10000. At least on Macs,
AFAIK, we have only 64k or 128k of IOs available.

No, the regions are larger. Apple's doc talks about '23 bits of IO
space', which is 8M, at least for the first-generation bridges (bandit,
that is).

Anyway, the best way to find out the size of this region (unless you can
read it from the bridge) is to look at the OF device tree, and the
bridge's region properties.

Cheers

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/

No, the regions are larger. Apple's doc talks about '23 bits of IO
space', which is 8M, at least for the first-generation bridges (bandit,
that is).

Anyway, the best way to find out the size of this region (unless you can
read it from the bridge) is to look at the OF device tree, and the
bridge's region properties.

Well, if IO decoding works like memory decoding on those bridges, then
yes, the region size is either 256 or 16Mb (large or sparse decoding).
The way it's currently setup by the BIOS, I beleive it's 16Mb. It's
possible that only 8MB out of the 16 are actually useable, we really lack
documentation about those chips.

Ben.

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

On Fri, 13 Oct 2000, Benjamin Herrenschmidt wrote:

quoted

But you can fixup all pci_dev's so bus 0 takes 0x00000-0x0fffff, bus 1 takes
0x10000-0x1ffff, and so on. ioportremap() finds out the bus by looking at the
region.

I/O space is not limited to 64 kB on non-ia32, we can use the full size of an
unsigned long.

Legacy I/O mappings (`I have legacy lp0 on bus 0 and legacy lp1 on bus

1') can

quoted

be sorted out in ioportremap() as well.

Ok, If I follow you correctly, that mean that if we have, for example,
bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
in this range, the address + bus_io_base - 0x10000. At least on Macs,
AFAIK, we have only 64k or 128k of IOs available.

Right.

After that `#define inb	readb' etc. and almost all overhead is gone.

And if you want to map legacy VGA I/O to bus X, you can handle this in
ioportremap(). Since ioportremap() is called only once, the complexity there
isn't of much importance.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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