Date: Wed, 19 Jan 2000 00:16:09 -0700 From: Warner Losh <imp@village.org> To: "Matthew N. Dodd" <winter@jurai.net> Cc: current@FreeBSD.ORG Subject: Re: Problems with PCMCIA Cards Message-ID: <200001190716.AAA23745@harmony.village.org> In-Reply-To: Your message of "Wed, 19 Jan 2000 01:59:04 EST." <Pine.BSF.4.21.0001190155180.462-100000@sasami.jurai.net> References: <Pine.BSF.4.21.0001190155180.462-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0001190155180.462-100000@sasami.jurai.net> "Matthew N. Dodd" writes: : Ok, I'm obviously missing something here... You mean the IRQs specified : in /etc/pccard.conf are a complete crapshoot? Well, yes. The IRQs are supposed to be free AND ROUTABLE TO THE PCIC part. If they are, then it works great. If they aren't, then we lose bigtime. : We're pulling rabbits out : of a hat? Jesus. How does Windows deal with this? Poorly. Actually, with the new cardbus hardware, more information can be known. Enough to do our jobs. Enough for windows to not suck. Back in the bad old days before plug and pray, pcic was a black art on many machines. About the only saving grace was that pcic parts were more fully wired then. Maybe we can at least do a first order approximation by only trying IRQs that are marked as being for plug and play/PCI use. That wouldn't be that hard to implement, if the PCI BIOS interface is any good in modern -current kernels. : Can the PCIC : hardware be told to generate an interrupt? Can we use this during the : device probe/attach to generate a list of IRQs that the PCIC can route : to? No. Not really. If there is a card in the slot when we boot, we can check to see if it is cool or not. We can even defer this until after the spl is lowered (did peter ever make that change?). We can then try all the free IRQs that we can grab and see if an interrupt happens. If so, then we go ahead and add it to our list of possibilities. If not, then we don't. We should then be able to map which IRQs are available for the pcic to use. Later, we grab from this list. However, all bets are off if the card isn't inserted at boot. Hmmm, now that I'm thinking about this (and annoyed about it all at the same time), we could register a timeout by default. This timeout would poll the card until a card is there. Jump to the middle of the last paragraph and life is good, or at least less evil. This is mildly evil, but at the same time it seems clever and the right thing to do, given all the constraints. Can any of the newbus gurus comment on this plan? Oh, there are some cardbus bridges that need to have the PCI BIOS to configure them properly, or that won't even interrupt at all for the card events, so those bridges might still need to propigate hints down to the pcic/pccard layer in the kernel. Actually, for those cards, we can do a further evil hack for cards that know there should have been an interrupt but wasn't (I'm talking interrupts for the card's hardware, not interrupts for the card comings and goings). We can have an interface called something like PCCARD_IRQ_A_BAD_CALL_TRY_AGAIN, which would rebind a new IRQ to the cards interrupt routine in mid air. A corrective "I shot myself in the foot, please sir may I have another" sort of thing when it notices that timeouts happen rather than interrupts. Big nasty warnings could happen then and we'd try another IRQ until the gun goes "click click click" at which point we ignore further calls and let performance suck. : Granted this is rather ugly but we can do this last and only test : free IRQs and complain when we lack free ones but we should be able to at : least get the kernel to bitch and moan when it can't figure things out : rather than confusing people when their ethernet cards fail to function : and stuff like that. AMEN TO THAT BROTHER! I'll have to see if there is time to prototype this and the other stuff that needs to go into the pccard code before the release. I like the idea of experimenting with the oldcard for this and then using that technology on newcard. The problem is that pccardd needs to know too much about the interrupts to use. :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001190716.AAA23745>