diff options
author | Aaron Campbell <aaron@cvs.openbsd.org> | 2000-06-28 17:48:11 +0000 |
---|---|---|
committer | Aaron Campbell <aaron@cvs.openbsd.org> | 2000-06-28 17:48:11 +0000 |
commit | 936fdbed9f068647891331d9aa6e8b5a3438a274 (patch) | |
tree | e7172b8fbfa6e379f4f2a361a496d59e02ed1010 /games/fish | |
parent | d778f0732491665c2fcfde91332f64c6fe9f2764 (diff) |
Make suspend -> eject card -> resume work.
On suspend, the apm code calls each function in its powerhook list. This list
contains pointers to functions that are to be executed on PWR_SUSPEND and
PWR_RESUME. One of these functions is pcmcia_power() which calls xxx_activate()
for each PC Card that is connected with the action DVACT_ACTIVATE (where xxx
is the name of the driver for the PC Card). On resume, the same thing happens,
except the action is DVACT_ACTIVATE.
Clearly, if a card is gone when we resume, trying to activate it is a bad idea.
This commit adds a pcic_power() function that runs before pcmcia_power(). On
resume, it uses pcic_intr_socket() to detect any events that occurred while we
were suspended. (I had to split pcic_event_thread() into a threaded part and
a non-threaded part, since the thread will not run when we are in interrupt
context, but I need the events to be processed before pcmcia_power() runs.) So,
by the time pcic_power() is through, all events that occurred during suspend
have been processed, and pcmcia_power() will not try to activate cards that are
not there since they have already been completely and properly detached.
Note that event handling for card removals first calls the deactivate functions
on the card then the detach functions. When we suspend, apm does the deactivate
for us. So on resume, if we detect a card has been removed, we skip the
deactivation step and just detach. We use the DVF_ACTIVE bit to determine
whether or not deactivation has already occurred. Deactivating a device that
has already been deactivated causes a panic.
Diffstat (limited to 'games/fish')
0 files changed, 0 insertions, 0 deletions