lift the ioport_resource limit ...

lift the ioport_resource limit ...

[Jun Sun]

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

Re: lift the ioport_resource limit ...

[Ralf Baechle]

On Wed, May 09, 2001 at 10:35:12AM -0700, Jun Sun wrote:

> 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. 

ISA?

   Ralf

Re: lift the ioport_resource limit ...

[Jun Sun]

Ralf Baechle wrote:
> 
> On Wed, May 09, 2001 at 10:35:12AM -0700, Jun Sun wrote:
> 
> > 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.
> 
> ISA?
> 
>    Ralf

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

Re: lift the ioport_resource limit ...

[Maciej W. Rozycki]

On Wed, 9 May 2001, Jun Sun wrote:

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

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: lift the ioport_resource limit ...

[Geert Uytterhoeven]

On Thu, 10 May 2001, Maciej W. Rozycki wrote:
> On Wed, 9 May 2001, Jun Sun wrote:
> > The PCI IO space essentially extends the ISA bus, which effectively removes
> > the 0xffff limits.
> 
>  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. 

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)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: lift the ioport_resource limit ...

[Maciej W. Rozycki]

On Thu, 10 May 2001, Geert Uytterhoeven wrote:

> 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
> necessary.

 Excellent.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: lift the ioport_resource limit ...

[Jun Sun]

"Maciej W. Rozycki" wrote:
> 
> On Wed, 9 May 2001, Jun Sun wrote:
> 
> > The PCI IO space essentially extends the ISA bus, which effectively removes
> > the 0xffff limits.
> 
>  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.
> 

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

Re: lift the ioport_resource limit ...

[Ralf Baechle]

On Thu, May 10, 2001 at 11:11:53AM -0700, Jun Sun wrote:

> 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.

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