Date: Mon, 13 Apr 1998 10:40:56 +0200 (MDT) From: Matthias.Apitz@SOFTCON.de To: nate@mt.sri.com (Nate Williams) Cc: hackers@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: O2Micro OZ6832 && 3c589D && FreeBSD 2.2.6 Message-ID: <9804131040.AA25125@kant.SOFTCON.de> In-Reply-To: <199804101619.KAA19908@mt.sri.com> from "Nate Williams" at Apr 10, 98 10:19:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote:
> I have a brand new notebook with a O2Micro OZ6832 PCI CardBus
> bridge and a 3Com Etherlink III 3c589D PCMCIA network card.
...
[ Interrupts are not being delivered to the if_ep driver ]
> the 3c589D *or* doesn't get interrupts from the 3c589D. At the
> moment I think the latter is true.
>
> BTW: all other functions like IRQ for card changes, card
> detection in user-land in the /etc/pccardd.conf etc. are working
> fine.
Note, there is a 'polling' function that polls the PCIC to get the
insertion/removal events which could cause those to work. Also note
that the insertion/removal events are in a different function of the
PCIC that may be working.
*sigh* :-((
You're right (and I saw the timeout funtion for insertion/removal events
already) but after disabling the polling it turns out that also
steering of IRQ's for card changes doesn't work. BTW: the notebook
has a small additional LCD display for battery status etc. There is
also a symbol for the PCMCIA access and the symbol was blinking all
the time. After disabling the timeout function for polling in
pccard/pcic.c the blinking stops. Under Win95 the symbol is also
blinking all the time (I alreday asked the dealer if this is
normal or not). Perhaps Win95 does some polling on the PCIC also?
The bottom line of that is that the PCIC doesn't steer IRQ's for
i/o *and* for card status changes. I've read the spec of the
chip again and again and compared my register dumps with the spec...
I'll contact the folks at O2Micro again for that problem.
There is also one thing I don't understand in the O2Micro spec
(and in the source code pci/pcic_p.c too). In the PCI configuration
space of the OZ6832 is at offset 0x10 the "PC Card Socket Status/Control
Register Base Address" and at offset 0x44 the "PC Card 16-bit IF
Legacy Mode Base Address". The latter one is initialized from the
BIOS with 0x3e0 while the addr at offset 0x10 is zero. The code
in pci/pcic_p.c has a dump-function to print the PCI configuration
space, the PC Card Socket... Registers and the ExCA Registers and
uses the zero addr from 0x10 for that. Does the code assumes that
there is a real addr in 0x10 of the PCI configuration space?
Must there a real addr and from where to get this addr if not from BIOS?
The spec of the OZ6832 doesn't explain that problem. It just
says that there is some addr at 0x10 and period. For that reason I've
also found no way to access the Card Socket Status/Control Registers
itself (only their reflection bits in the ExCA registers). Maybe
that's the reason why the IRQ steering isn't working. Is someone out
there who can bring a little light into that?
matthias
--
firm: matthias.apitz@sisis.de [voc:+49-89-61308-351, fax: +49-89-61308-188]
priv: guru@thias.muc.de
PGP: Key fingerprint = 0C 01 F2 23 EC 17 A2 D5 46 2D 29 4C 0E 8B 7E 8F
URL: http://www.sisis.de/~guru/ http://www.muc.de/~thias/
from USENET:
People who run servers understand that flashy interactive interfaces have
nothing to do with the underlying functionality and often get in the way.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9804131040.AA25125>