Date: Tue, 23 Jul 2002 20:25:04 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: john@utzweb.net Cc: tony@valemount.com, mobile@FreeBSD.ORG, andrew@unfortu.net Subject: Re: PCI -> PCMCIA Adapter woes - patch Message-ID: <20020723.202504.103905350.imp@bsdimp.com> In-Reply-To: <Pine.LNX.4.44.0207240149440.23175-100000@jupiter.linuxengine.net> References: <20020723.150649.12657684.imp@bsdimp.com> <Pine.LNX.4.44.0207240149440.23175-100000@jupiter.linuxengine.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.LNX.4.44.0207240149440.23175-100000@jupiter.linuxengine.net>
John Utz <john@utzweb.net> writes:
: Yah, i know there is newer mail on this thread, but the issue that i find
: to be most important is addressed quite well by MWL.....
:
: On Tue, 23 Jul 2002, M. Warner Losh wrote:
:
: > In message: <0f5001c23287$1a948530$114c35d1@tonyxp>
: > "Tony Toole" <tony@valemount.com> writes:
: > : Here is my patch to solve the problem you are having. It works very well,
: > : and you can use regular PCI IRQ routing with no /boot/loader.conf tweaks
: > : needed. NEWCARD also had the same problem, so this patch with subtle
: > : changes should fix it as well.
: > :
: > : I have included the patch as an attachment as email tends to mangle them.
: >
: > First off, the IRQMUX register is 12xx and newer. The documentation
: > for the MUX register indicates that it should be programmed once by
: > the eeprom that's on the board. Chances are that this is a workaround
: > for a bug in the card in question.
: >
: > However, a reasonable thing to do would likely be to do this if the
: > low nibble of the word was 0 (configuring it for a GPIO input, that
: > the code never uses), then set it up to do PCI signalling.
: >
: > I'm a little loathe to do this by default, because the docs say that
: > you have to have terminal resistors on these multifuction pins to use
: > them as outputs.
:
: I would be way loathe, IMHO. If you dont have the pullups ( the
: terminating resistors ) then you are basically gambling that card 'design
: slop' and chip fabrication process 'fudge factors' all work out in your
: favor. :-(
:
: The resistors 'hold the voltage up' and limit the current thru that
: portion of the circuit.
:
: If the chip has a lot of it's circuitry in parallel with that pin, which
: likely if it's multifunction, because that pin is designed to do more
: things than usual??.
:
: Next, if the card designer didnt keep the impedence of his portion of the
: design pretty high, then every time the chip tries to assert (set to
: logical high) that pin ( or, heaven help you, *several* of them at the
: same time ) then you will be mistreating that chip quite badly and it will
: at the very least 'act weird' and at the worst, fry.
:
: I dont think that the frying is likely, but 'act weird' is the
: one that i'd be betting on.
:
: And, if the card cost us$40.00, and you've spent the last N weeks of
: billable hours ( at a rate >=us$40.00/hr ) trying to figure out why the
: card 'spazzes out' periodically....wouldnt you have rathered that it had
: just cooked and died in the first few minutes and left a big cloud of
: smoke and an obviously discolored part on the PCB?
:
: :-)
Yes. That's what I'm loathe to do it. However, I think that some of
these lines need to be routed, and that the mux register won't be
zero. I'll take a look and see if there's something that I can be
sure of before we do this.
: > However, given that this is the only way I know to drive the PCI bus, it
: > may make good sense to do it anyway.
:
: eek! i defer to your expertise.
That's just an educated guess. I've been known to be wrong before.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020723.202504.103905350.imp>