Date: Wed, 01 Dec 1999 22:55:06 -0700 From: Warner Losh <imp@village.org> To: Mike Smith <msmith@FreeBSD.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: <199912020555.WAA00484@harmony.village.org> In-Reply-To: Your message of "Wed, 01 Dec 1999 21:39:30 PST." <199912020539.VAA00927@mass.cdrom.com> References: <199912020539.VAA00927@mass.cdrom.com>
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.
: This really makes it imperative for the interrupt handler itself to be
: able to test for the hardware. The logic should probably go something
: like:
:
: dev_intr()
: {
: for(;;) {
: if (sc->device_is_removable && !bus_device_present()) {
: revoke_device(); /* disables interrupt */
: return;
: }
Race here between bus present check. Small window, I'll grant, however.
: if (!device_needs_attention(sc))
: return;
: ...
: Oh, and I forgot with the CardBus thing above; if the slot is sharing an
: interrupt with someone else, you're probably screwed as well. (Unless the
: bus lets you call back into it to disable a slot once you've detected
: that it's gone.)
I believe that it is common practice to share the cardbus card
interrupt with the cardbus bridge, but I may be mistaken about that.
: 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'll have to keep all this in mind as I move forward with cardbus/pc
card stuff in the newcard.
BTW, I just committed MIHIRA-san's port of the PAO power code, since
it looks like it would be good for testing purposes.
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?199912020555.WAA00484>