Subject: lift the ioport_resource limit ...

From: Jun Sun <[email-masked]>
Date: Wed, 09 May 2001 10:35:12 -0700

Currently IO_SPACE_LIMIT is 0xffff, which is probably borrowed from the legacy
i386 code.  Let us remove that limit, so that each machine does not have to
laboriously reset it. 

BTW, a prudent machine port should probably always reset it to a more sane
range - in any case having 0xffff default value does not make much sense.

Jun

diff -Nru linux/include/asm-mips/io.h.orig linux/include/asm-mips/io.h
--- linux/include/asm-mips/io.h.orig    Fri Feb  9 16:43:15 2001
+++ linux/include/asm-mips/io.h Wed May  9 10:26:44 2001
@@ -436,7 +436,7 @@
        __inslc((port),(addr),(count)) : \
        __insl((port),(addr),(count)))
 
-#define IO_SPACE_LIMIT 0xffff
+#define IO_SPACE_LIMIT 0xffffffff
 
 /*
  * The caches on some architectures aren't dma-coherent and have need to

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 9 May 2001 16:26:08 -0300

> i386 code.  Let us remove that limit, so that each machine does not have to

ISA?

   Ralf

---

From: Jun Sun <[email-masked]>
Date: Wed, 09 May 2001 14:06:59 -0700

> > i386 code.  Let us remove that limit, so that each machine does not have to

ISA bus?

The PCI IO space essentially extends the ISA bus, which effectively removes
the 0xffff limits.

If you are really paranoid, we can do something like this:

#if defined(CONFIG_ISA) && !defined(CONFIG_PCI)
#define IO_SPACE_LIMIT 0xffff
#else
#define IO_SPACE_LIMIT 0xffffffff
#endif

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 10 May 2001 11:43:36 +0200 (MET DST)

> The PCI IO space essentially extends the ISA bus, which effectively removes

 Note that while there is usually no problem with using addresses beyond
64kB in the PCI I/O space, certain PCI-to-PCI bridges may not pass such
accesses across.  So it's best to avoid assigning and using them.  That's
why Linux remaps "high" I/O space resources on Alpha, which get set up for
some systems by the SRM console (firmware), e.g. in the system I was using
a few years ago, SRM used to assign addresses around 0x11000 and 0x12000
for the onboard network and SCSI devices, IIRC. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Geert Uytterhoeven <[email-masked]>
Date: Thu, 10 May 2001 11:58:51 +0200 (MET DST)

> for the onboard network and SCSI devices, IIRC. 

Shouldn't that be reflected in the bridge's bus resources (pci_bus.resource[])?
Then the PCI resource validation/assignment code will (re)assign them when
necessary.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 10 May 2001 13:08:31 +0200 (MET DST)

> Shouldn't that be reflected in the bridge's bus resources (pci_bus.resource[])?

 No idea -- if you write so then you are probably right.  I was told of
the problem at about 2.1.85 and I haven't investigated it further.  Our
PCI handling code wasn't so brillant as it is now, I guess. 

> Then the PCI resource validation/assignment code will (re)assign them when

 Excellent.

---

From: Jun Sun <[email-masked]>
Date: Thu, 10 May 2001 11:11:53 -0700

> for the onboard network and SCSI devices, IIRC.

I would not normally assign IO space above 0xffff either.  But recently I
found multiple PCI buses, especially dual PCI buses, are getting popular, as
examplified by two Gallelio chips and the new NEC Vrc5477 chips.  

Since all drivers share the same mips_io_port_base, - even though the devices
may be on different PCI buses - we need to assign the PCI IO windows
contiguously so that drivers can share the same base address.  In most such
setups, you will get more than 0xffff IO ranges.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 10 May 2001 17:20:18 -0300

> setups, you will get more than 0xffff IO ranges.

After some discussion with some of the Linux PCI guys I think we should try
to avoid extend the per-bus I/O address space beyond 64k ports.  This is not
a very strong ``should avoid'', though.  The primary concern is a number of
broken peripheral chips which apparently are floating around out there in
good numbers.

Another reason to not extend the PCI-bus address range to 4g ports is the
size of the available physical address space in the main processor's
address space itself.  Limited by the 32-bit address space we can only
address a limited number via in/out anyway, so we better shouldn't fake
what we ain't got (cited freely after Seymoure Cray), so 4g ports is silly
anyway.

  Ralf