## Input/Output Device Driver Reference

[prev][next][parent][TOC]

### Event Processing Flow

The following is a generalized event processing flow for the definition of responsibilities within the OS/2 PCMCIA environment. The following steps are provided for the CARD_INSERTION and CARD_REMOVAL events.

Note: The following scenario has been simplified for descriptive purposes. In addition, the defined scenario represents only the actions used to manage I/O card support. There are numerous combinations of Card Services and Socket Services functions, as well as ordering differences, when this scenario is broadened to include other events.

1.Hardware Interrupt (Adapter)

The user inserts a PCMCIA Card into a socket. The adapter raises a Status Change interrupt to Card Services. Card Services, which has installed interrupt handlers for each adapter, calls the Socket Services AcknowledgeInterrupt (9Eh) function to retrieve the socket ID that generated the interrupt. Card Services sets up a global context hook handler to process the interrupt, issues the EOI for the adapter IRQ, and returns from the interrupt.

2.CARD_INSERTION Events

a.When the Card Services context hook handler gets control, it processes the pending interrupt information by calling the Socket Services GetStatus (8Fh), GetSocket (8Dh), and SetSocket (8Eh) functions to retrieve the specific interrupt meaning. In this scenario, the CardState and SocketState field values indicate a card insertion. Therefore, the Card Services timer handler creates CARD_INSERTION events and sends them to all client device drivers registered for the affected socket.

b.Each client device driver registered for the socket receives a CARD_ INSERTION event notification. Client device drivers process the event by calling the Card Services GetConfigurationInfo (04h) function to determine if the card has been claimed by another client and to identify the card's attributes. The client might also query more card data from the Card Information Structure (CIS) tuples by using the Card Services GetFirstTuple (07h), GetNextTuple (0Ah), and GetTupleData (0Dh) functions.

If the client determines that the card cannot be supported, it returns from the event notification. If the client determines that the card can be supported, it uses the Card Services RequestIO (1Fh), RequestIRQ (20h), and RequestConfiguration (30h) functions to allocate resources to manage the card. If the resources are not available, the client returns from the event notification. If the resources are available, the client issues a DevHlp_ SetIRQ request to hook its interrupt handler into the operating system's IRQ chain.

Clients that use the COM IDC function should issue the Install function at this time, to map the device into the general COM application support. See COM Support for more details.

Note: Clients might receive two event notifications if the local and global event masks both have CARD_INSERTION events selected by way of the Card Services RegisterClient (10h) and SetEventMask (31h) functions.

c.Card Services processes the RequestConfiguration function (30h) by calling Socket Services SetSocket (8Eh) to program the adapter/card to the configuration information that has been locked for that socket.

3.Normal Device Activity

The client device driver uses the card-configured resources to perform normal device-specific manipulations, such as reading and writing data, processing device interrupts, and enacting device commands.

4.Hardware Interrupt (Adapter)

The user removes a PCMCIA Card from a socket. The adapter raises a Status Change interrupt to Card Services. Card Services calls the Socket Services AcknowledgeInterrupt (9Eh) function to retrieve the socket ID that generated the interrupt. Card Services sets up the interrupt processing context hook handler, issues the EOI for the adapter IRQ, and returns from the interrupt.

5.CARD_REMOVAL Events

a.When the Card Services timer handler gets control, it processes the pending interrupt information by calling the Socket Services GetStatus (8Fh ), GetSocket (8Dh), and SetSocket (8Eh) functions to retrieve the specific interrupt meaning. In this scenario, the CardState and SocketState field values indicate a card removal. Therefore, the Card Services timer handler creates CARD_REMOVAL events and sends them to all client device drivers registered for the affected socket.

b.Each client device driver registered for the socket receives a CARD_ REMOVAL event notification. Client device drivers process the event by releasing Card Services resources (for example, by calling the Card Services ReleaseConfiguration (1Eh), ReleaseIO (1Bh), and ReleaseIRQ (1Ch) functions). In addition, the client device driver releases system resources (for example, by calling the DevHlp_UnsetIRQ function).

Clients that use the COM IDC functions should issue the Deinstall function at this time to map the device into the general COM application support. The COM IDC client should issue the Deinstall function prior to releasing the Card Services resources or system resources associated with the device. See COM Support for more details.

c.Card Services processes the ReleaseConfiguration request by calling Socket Services Set Socket (8Eh) to reprogram the socket so that it stops generating interrupts and cannot be accessed through the previously configured I/O addresses.

d.Card Services processes the ReleaseIO (1Bh) and ReleaseIRQ (1Ch) functions by returning the referenced resources to the resource map. This makes them available for subsequent request function calls.