Card Services events have several sources:
Socket driver events may be either interrupt-driven or polled.
When Card Services recognizes that an event has occurred, it checks the event mask of each client to determine which clients should receive an event notification. When a client registers with Card Services, it specifies an event handler callback function. This handler should have the form:
int (*event_handler)(event_t event, int priority, event_callback_args_t *args);
The priority parameter is set to either CS_EVENT_PRI_LOW for
ordinary events, or CS_EVENT_PRI_HIGH for events that require an
immediate response. The only high priority event is
CS_EVENT_CARD_REMOVAL. A client event handler should process
this event as efficiently as possible so that Card Services can
quickly notify other clients.
The event_callback_args_t structure is given by:
typedef struct event_callback_args_t {
client_handle_t client_handle;
void *info;
void *mtdrequest;
void *buffer;
void *misc;
void *client_data;
} event_callback_args_t;
The client_handle member is set to the handle of the client whose
socket was responsible for the event. This is useful if a driver is
bound to several sockets. The info field is currently only used
to return an exit status from a call to ResetCard. The
client_data field may be used by a driver to point to a local
data structure associated with this device. The remaining
fields are currently unused.
CS_EVENT_CARD_INSERTIONThis event signals that a card has been inserted. If a driver is bound to an already occupied socket, Card Services will send the driver an artificial insertion event.
CS_EVENT_CARD_REMOVALThis event signals that a card has been removed. This event should be handled with minimum delay so that Card Services can notify all clients as quickly as possible.
CS_EVENT_BATTERY_LOWThis event signals a change of state of the ``battery low'' signal.
CS_EVENT_BATTERY_DEADThis event signals a change of state of the ``battery dead'' signal.
CS_EVENT_READY_CHANGEThis event signals a change of state of the ``ready'' signal.
CS_EVENT_WRITE_PROTECTThis event signals a change of state of the ``write protect'' signal.
CS_EVENT_REGISTRATION_COMPLETEThis event is sent to a driver after a successful call to
RegisterClient.
CS_EVENT_RESET_REQUESTThis event is sent when a client calls ResetCard. An event
handler can veto the reset operation by returning failure.
CS_EVENT_RESET_PHYSICALThis is sent to all clients just before a reset signal is sent to a card.
CS_EVENT_CARD_RESETThis event signals that a reset operation is finished. The success or
failure of the reset should be determined using GetStatus.
CS_EVENT_RESET_COMPLETEThis event is sent to a client that has called ResetCard to
signal the end of reset processing.
CS_EVENT_PM_SUSPENDThis event signals that Card Services has received either a user initiated or APM suspend request. An event handler can veto the suspend by returning failure.
CS_EVENT_PM_RESUMEThis signals that the system is back on line after a suspend/resume cycle.
CS_EVENT_MTD_REQUESTThis is used to initiate an MTD memory operation. A description of
the request is passed in the mtdrequest field of the callback
arguments. A host buffer address may be passed in buffer.
CS_EVENT_ERASE_COMPLETEThis is used to signal a client that a queued erase operation has
completed. A pointer to the erase queue entry is returned in the
info field of the callback arguments.
A client driver should respond to CS_EVENT_CARD_INSERTION and
CS_EVENT_CARD_REMOVAL events by configuring and un-configuring
the socket. Because card removal is a high priority event, the driver
should immediately block IO to the socket, perhaps by setting a flag
in a device structure, and schedule all other shutdown processing to
happen later using a timer interrupt.
When a CS_EVENT_PM_RESET_REQUEST event is received, a driver
should block IO and release a locked socket configuration. When a
CS_EVENT_CARD_RESET is received, a driver should restore the
socket configuration and unblock IO.
A CS_EVENT_PM_SUSPEND event should be handled somewhat like a
CS_EVENT_PM_RESET_REQUEST event, in that IO should be blocked and
the socket configuration should be released. When a
CS_EVENT_PM_RESUME event is received, a driver can expect a card
to be ready to be reconfigured, similar to when a
CS_EVENT_CARD_RESET event is received.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter