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>