Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Back out rev 1.7 of i82365_isa.c; 0x300-0x3ff, or even 0x330-0x3ff

Browse Source 
is not a reasonable place to allocate 12-bit pcmcia iospace.
It seems to cause conflicts on a large number of modern laptops,
necesitating hand-patching of the kernel (mostly due to
video devices in the upper range of that space).

This will presumably cause problems on the NEC Versa 6030X,
however that appears to be a vastly less common case than
the laptops that are inconvenienced by the current state.

12-bit iospace now uses 0x400-0xfff.
This commit is contained in:
jhawk 2000-05-09 17:59:39 +00:00
parent 05e928a241
commit e02d0e3597
2 changed files with 10 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
share/man/man4/pcmcia.4
View File

@ -1,4 +1,4 @@
.\" $NetBSD: pcmcia.4,v 1.15 2000/04/13 19:40:03 jhawk Exp $
.\" $NetBSD: pcmcia.4,v 1.16 2000/05/09 17:59:39 jhawk Exp $
.\"
.\" Copyright (c) 1999 The NetBSD Foundation, Inc.
.\" All rights reserved.
@ -143,16 +143,12 @@ driver appeared in
.Nx
probes the pcmcia IO bus width and uses that information to decide
where to map PCMCIA IO space. For 10-bit wide cards, 0x300-0x3ff is
used, and this is satisfactory. For 12-bit wide cards, however,
it would nice to use 0x400-0xfff, however this causes some problems
for some specific PCMCIA devices, as well as some specific laptops;
consequently, 0x300-0x3ff is used.
used. For 12-bit wide cards, 0x400-0x4ff is used.
.Pp
Unfortunately, the choice of 0x300-0x3ff causes problems as well.
In particular, a number of video devices are mapped in that range,
and may conflict. In the event that pcmcia devices are mapped
in 0x300 and appear to be nonfunctional, remapping to 0x400-0xfff
may be appropriate; consult
Neither choice is perfect. In the 12-bit case, 0x400 appears to work
on substantially more devices than 0x300. In the event that pcmcia
devices are mapped in 0x400-0xfff and appear to be nonfunctional,
remapping to 0x300-0x3ff may be appropriate; consult
.Cd options PCIC_ISA_ALLOC_IOBASE
and
.Cd options PCIC_ISA_ALLOC_IOSIZE
@ -161,7 +157,7 @@ in
Example:
.Bd -literal -offset indent
# Avoid pcmcia bus space conflicts with the default io space
# allocation on 12-bit wide busses (base 0x300 size 0xff).
options PCIC_ISA_ALLOC_IOBASE=0x400
options PCIC_ISA_ALLOC_IOSIZE=0xbff
# allocation on 12-bit wide busses (base 0x400 size 0xfff).
options PCIC_ISA_ALLOC_IOBASE=0x300
options PCIC_ISA_ALLOC_IOSIZE=0x0ff
.Ed

21
sys/dev/isa/i82365_isasubr.c
View File

@ -1,4 +1,4 @@
/* $NetBSD: i82365_isasubr.c,v 1.20 2000/02/28 05:30:19 enami Exp $ */
/* $NetBSD: i82365_isasubr.c,v 1.21 2000/05/09 17:59:39 jhawk Exp $ */
#define PCICISADEBUG
@ -428,11 +428,6 @@ void pcic_isa_bus_width_probe (sc, iot, ioh, base, length)
bus_space_free(iot, ioh_high, length);
/*
* XXX mycroft recommends I/O space range 0x400-0xfff . I should put
* this in a header somewhere
*/
/*
* XXX some hardware doesn't seem to grok addresses in 0x400 range--
* apparently missing a bit or more of address lines. (e.g.
@ -447,22 +442,8 @@ void pcic_isa_bus_width_probe (sc, iot, ioh, base, length)
sc->iobase = 0x300;
sc->iosize = 0x0ff;
} else {
#if 0
/*
* This is what we'd like to use, but...
*/
sc->iobase = 0x400;
sc->iosize = 0xbff;
#else
/*
* ...the above bus width probe doesn't always work.
* So, experimentation has shown the following range
* to not lose on systems that 0x300-0x3ff loses on
* (e.g. the NEC Versa 6030X).
*/
sc->iobase = 0x330;
sc->iosize = 0x0cf;
#endif
}
DPRINTF(("%s: bus_space_alloc range 0x%04lx-0x%04lx (probed)\n",