Date: Thu, 02 Dec 1999 00:31:47 -0800 From: Mike Smith <msmith@freebsd.org> To: Warner Losh <imp@village.org> Cc: mobile@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pccard pccard.c src/sys/isa sio.c src/sys/dev/ed if_ed_pccard.c src/sys/dev/ep if_ep_pccard.c Message-ID: <199912020831.AAA00418@mass.cdrom.com> In-Reply-To: Your message of "Wed, 01 Dec 1999 22:55:06 MST." <199912020555.WAA00484@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199912020539.VAA00927@mass.cdrom.com> Mike Smith writes: > : This actually becomes much more complex when you bring CardBus into the > : picture, as I believe (correct me if I'm wrong, since you have the spec > : there) that it uses level-triggered interrupts. In this case, the device > : interrupt handler can't return (well, it can, but it will be immediately > : re-entered). > > Yes. Both cardbus and pccard use level triggered interrupts (or can > use level triggered interrupts). But if the card goes away, the > bridge, I believe, deasserts the interrupt for the card. Hmmm. > Actaully, it doesn't say that in the spec, so I'll have to look at my > datasheets to see what it does for sure. I've certainly seen interrupt-on-removal behaviour on a considerable number of PCIC bridges; I originally fixed 'ed' for it due to whatever Sharp were using ~3 years ago, the Toshiba ToPIC'97 does it, and whatever's in this Dell i7500 does it too in PCIC mode. Since these are all "ISA" behaviour cases, it's just the single interrupt leaking out that's caused the problem to date. > : Hmm, thinking about it more, that would suggest that the "right" thing > : would be a bus method that is the equivalent of our current slot poll - > : the device driver checks the slot if it thinks the peripheral is acting > : up; the bus code can then call the detach routine, kill the interrupt > : off, etc. and the driver gets a return value that it can test in order to > : decide whether the device has been killed off. That would avoid all the > : mess with reference counting, etc. and only leave code elsewhere in the > : driver that's using the softc. You'd have to mask interrupts for that. 8( > > Yes. One would :-< I can think of accessor techniques that'd make it a little easier (mask interrupts, cache relevant softc contents, unmask), but even then you still lose if eg. you have a mapped memory aperture. > I'll have to keep all this in mind as I move forward with cardbus/pc > card stuff in the newcard. You may want one of those 16k brain expansion modules for all this. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?199912020831.AAA00418>