PC Card Standard 8.0 Volume 5 Card Services Specification

8/2/2019 PC Card Standard 8.0 Volume 5 Card Services Specification

1/240

PC CARD STANDARD

Volume 5

Card Services Specification


2/240

REVISION H ISTORYDate Card Services

Specification VersionPC Card StandardRelease

Revisions

11/92 2.0 PCMCIA 2.01 Initial release

07/93 2.1 PCMCIA 2.1/JEIDA 4.2 Added Services

Editorial corrections02/95 5.0 February 1995 (5.0)

ReleaseAdded support for CardBus PC Cards

Added Windows 16-bit Bindings

Added Services

Editorial corrections

03/95 N/A March 1995 (5.01) Update None

05/95 N/A May 1995 (5.02) Update None

11/95 5.01 November 1995 (5.1)Update

Added support for Custom Interfaces


05/96 5.02 May 1996 (5.2) Update Editorial corrections

03/97 6.0 6.0 Release Added support for Hot Dock/Undock

Added Streamlined PC Card Configuration

04/98 6.1 6.1 Update Added Win32 Bindings


02/99 7.0 7.0 Release Added Windows NT Bindings

Added support for PC Card Memory Paging


03/00 7.1 7.1 Update Added Latency Timer access toAccessConfigurationRegister

Noted July 1, 2000 removal of references to DMA (DirectMemory Access)

11/00 7.2 7.2 Update Removed all references to Direct Memory Access (DMA)

04/01 8.0 8.0 Release None

2001 PCMCIA/ JEITA

All rights reserved.

No p art of this publication m ay be reprodu ced, stored in a retrieval system, or transmitted, in any form or by any m eans,

mechanical, electronic, photocopying, recording or otherwise, without prior written permission of PCMCIA and JEITA.

Published in the United States of America.


3/240

CARD SERVICES SPECIFICATION

2001 PCMCIA/JEITA iii

CONTENTS

1. Introd uction ___________________________________________ 1

1.1 Pu rp ose ...........................................................................................................................................1

1.2 Scope................................................................................................................................................1

1.3 Related Documents .......................................................................................................................1

2. Overview _____________________________________________ 3

3. Fu nctional D escrip tion _________________________________ 5

3.1 Architectu re ....................................................................................................................................5

3.1.1 Ha rd wa re Layer (PC Card s, Sockets and Ad ap ters) ..................................................................................... 5

3.1.2 Socket Serv ices ....................................................................................................................................................6

3.1.3 Card Services ...................................................................................................................................................... 6

3.1.4 Mem ory Techn olog y Driver s............................................................................................................................6

3.1.5 Client Dev ice Driver s......................................................................................................................................... 7

3.2 Programming Interface.................................................................................................................7

3.2.1 Calling Con ven tion s .......................................................................................................................................... 7

3.2.1.1 Basic Op erat ion ....................................................................................................................................... 7

3.2.1.2 Argu ment Packet .................................................................................................................................... 8

3.2.1.3 Logical Sockets ........................................................................................................................................ 8

3.2.1.4 Reserved Field s ....................................................................................................................................... 8

3.2.1.5 Mu lti-Byte Fields .................................................................................................................................... 8

3.2.1.6 Mu ltiple Fun ction PC Car ds ................................................................................................................. 93.2.2 Presence Detection ............................................................................................................................................. 9

3.2.3 Initia lization of Car d Services........................................................................................................................... 9

3.2.4 Return Cod es ...................................................................................................................................................... 9

3.3 Service Grou ps .............................................................................................................................10

3.3.1 Clien t Serv ices................................................................................................................................................... 10

3.3.1.1 Clien t Regist rat ion ................................................................................................................................ 11

3.3.1.2 Basic Car d Sup port............................................................................................................................... 11

3.3.2 Resou rce Man agement .................................................................................................................................... 11

3.3.3 Bulk Mem ory Services .....................................................................................................................................12

3.3.4 Client Utilities ................................................................................................................................................... 13

3.3.5 Ad van ced Client Services................................................................................................................................ 13

3.4 Callback Inter faces ......................................................................................................................14

3.4.1 Insertion ............................................................................................................................................................. 15

3.4.2 Registr ation Com pletion ................................................................................................................................. 15

3.4.3 Status Change ................................................................................................................................................... 15

3.4.4 Ejection / Insertion Requ ests ............................................................................................................................ 16

3.4.5 Exclusive............................................................................................................................................................ 16


4/240

CONTENTS

iv 2001 PCMCIA/JEITA

3.4.6 Rese t ................................................................................................................................................................... 17

3.4.7 Clien t Inform ation ............................................................................................................................................ 17

3.4.8 Erase Com pletion ............................................................................................................................................. 17

3.4.9 MTD Requ est .................................................................................................................................................... 17

3.4.10 Timer .................................................................................................................................................................. 17

3.4.11 New or Removed Socket Services .................................................................................................................. 18

3.5 Even ts ............................................................................................................................................19

3.5.1 BATTERY_DEAD ............................................................................................................................................. 20

3.5.2 BATTERY_LOW............................................................................................................................................... 21

3.5.3 CARD_INSERTION ......................................................................................................................................... 22

3.5.4 CARD_LO CK.................................................................................................................................................... 23

3.5.5 CARD_READY................................................................................................................................................. 24

3.5.6 CARD_REMOVAL .......................................................................................................................................... 25

3.5.7 CARD_RESET................................................................................................................................................... 26

3.5.8 CARD_UN LOCK ............................................................................................................................................. 27

3.5.9 CLIEN T_INFO.................................................................................................................................................. 283.5.10 EJECTION _COMPLETE ................................................................................................................................. 29

3.5.11 EJECTION _REQUEST..................................................................................................................................... 30

3.5.12 ERASE_COMPLETE........................................................................................................................................ 31

3.5.13 EXCLUSIVE_COMPLETE............................................................................................................................... 32

3.5.14 EXCLUSIVE_REQUEST .................................................................................................................................. 33

3.5.15 INSERTION _COMPLETE............................................................................................................................... 34

3.5.16 INSERTION _REQUEST .................................................................................................................................. 35

3.5.17 PM_RESUME .................................................................................................................................................... 36

3.5.18 PM_SUSPEND.................................................................................................................................................. 38

3.5.19 REGISTRATION_COMPLETE....................................................................................................................... 40

3.5.20 REQUEST_ATTENTION ................................................................................................................................ 41

3.5.21 RESET_COM PLETE......................................................................................................................................... 42

3.5.22 RESET_PHYSICAL .......................................................................................................................................... 43

3.5.23 RESET_REQUEST............................................................................................................................................ 44

3.5.24 SS_UPDA TED................................................................................................................................................... 45

3.5.25 TIMER_EXPIRED ............................................................................................................................................. 46

3.5.26 WRITE_PROTECT ........................................................................................................................................... 47

3.6 Memory Techn ology Drivers .....................................................................................................48

3.6.1 Regist ra tion ....................................................................................................................................................... 48

3.6.2 Car d Services/ MTD In terface ........................................................................................................................ 48

3.6.3 MTD Helper Inte rface...................................................................................................................................... 513.6.4 Erase Qu eu ing .................................................................................................................................................. 51

3.6.5 Blockin g ............................................................................................................................................................. 51

3.6.6 Car d Services Requ est Retries ........................................................................................................................ 52

3.6.7 Med ia Access Table.......................................................................................................................................... 53

3.6.8 Virtu al Mem ory Par tition s/ Region s ............................................................................................................. 54

3.6.9 Tup le Usage ...................................................................................................................................................... 54


5/240


2001 PCMCIA/JEITA v

4. Assu mptions and Con strain ts __________________________ 57

4.1 Au to Con figuration of I/ O Cards .............................................................................................57

4.2 Com pression ................................................................................................................................57

4.3 EDC Gen eration ...........................................................................................................................57

4.4 BIOS or Dev ice Dr iver ................................................................................................................57

4.5 Interru pts Per Socket ...................................................................................................................57

4.6 Mixed Media Memory Card s.....................................................................................................57

4.7 Mu ltiple Par titioned Mem ory Cards ........................................................................................57

4.8 Use of Socket Services .................................................................................................................57

4.9 Interface Assumption s ................................................................................................................58

4.9.1 Range Ch ecking of Ar gu ment s ......................................................................................................................58

4.9.2 Con figura tion .................................................................................................................................................... 58

4.9.3 Abn orma l Term ina tion .................................................................................................................................... 584.9.4 Shared Data ....................................................................................................................................................... 58

4.10 Timeou ts ....................................................................................................................................58

5. Service Reference _____________________________________ 59

5.1 AccessConfigurationRegister (36H)..........................................................................................61

5.2 Add SocketServices (32H)............................................................................................................64

5.3 AdjustResourceInfo (35H) ..........................................................................................................65

5.4 CheckEraseQueu e (26H) .............................................................................................................71

5.5 CloseMemory (00H).....................................................................................................................72

5.6 ConfigureFun ction (3CH)...........................................................................................................73

5.7 CopyMemory (01H).....................................................................................................................74

5.8 DeregisterClient (02H) ................................................................................................................76

5.9 DeregisterEraseQueu e (25H)......................................................................................................77

5.10 GetCardServicesInfo (0BH) .....................................................................................................78

5.11 GetClientInfo (03H)..................................................................................................................80

5.12 GetConfigurationInfo (04H)....................................................................................................83

5.13 GetEventMask (2EH)................................................................................................................86

5.14 GetFirstClient (0EH).................................................................................................................88

5.15 GetFirstPartition (05H).............................................................................................................89

5.16 GetFirstRegion (06H)................................................................................................................93

5.17 GetFirstTup le (07H)..................................................................................................................94


6/240

CONTENTS

vi 2001 PCMCIA/JEITA

5.18 GetFirstWindow (37H).............................................................................................................96

5.19 GetMemPage (39H) [16-bit PC Card only] ..........................................................................97

5.20 GetNextClient (2AH)................................................................................................................98

5.21 GetNextPartition (08H)............................................................................................................99

5.22 GetNextRegion (09H).............................................................................................................101

5.23 GetNextTuple (0AH)..............................................................................................................102

5.24 GetNextWindow (38H)..........................................................................................................104

5.25 GetStatus (0CH) ......................................................................................................................105

5.26 GetTupleData (0DH) ..............................................................................................................107

5.27 InquireConfiguration (3DH) .................................................................................................109

5.28 MapLogSocket (12H)..............................................................................................................119

5.29 MapLogWindow (13H

) [16-bit PC Card on ly] ..................................................................1205.30 MapMemPage (14H) [16-bit PC Card on ly].......................................................................121

5.31 MapPhySocket (15H)..............................................................................................................122

5.32 MapPhyWindow (16H) [16-bit PC Card only]..................................................................123

5.33 ModifyConfiguration (27H) ..................................................................................................124

5.34 ModifyWindow (17H)............................................................................................................126

5.35 OpenMemory (18H) ...............................................................................................................128

5.36 ReadMemory (19H) ................................................................................................................130

5.37 RegisterClient (10H) ...............................................................................................................131

5.38 RegisterEraseQueue (0FH) ....................................................................................................133

5.39 RegisterMTD (1AH) ...............................................................................................................135

5.40 RegisterTimer (28H) ...............................................................................................................137

5.41 ReleaseConfiguration (1EH)..................................................................................................138

5.42 ReleaseExclusive (2DH) .........................................................................................................139

5.43 ReleaseIO (1BH) [16-bit PC Card only] ..............................................................................140

5.44 ReleaseIRQ (1CH) ...................................................................................................................142

5.45 ReleaseSocketMask (2FH)......................................................................................................143

5.46 ReleaseWindow (1DH) ..........................................................................................................144

5.47 ReplaceSocketServices (33H).................................................................................................145

5.48 RequestConfiguration (30H) .................................................................................................147

5.49 RequestExclusive (2CH) ........................................................................................................151


7/240


2001 PCMCIA/JEITA vii

5.50 RequestIO (1FH) [16-bit PC Card on ly]..............................................................................152

5.51 RequestIRQ (20H)...................................................................................................................155

5.52 RequestSocketMask (22H).....................................................................................................160

5.53 RequestWindow (21H)...........................................................................................................161

5.54 ResetFunction (11H)...............................................................................................................164

5.55 ReturnSSEntry (23H)..............................................................................................................166

5.56 SetEventMask (31H)...............................................................................................................167

5.57 SetRegion (29H) ......................................................................................................................169

5.58 ValidateCIS (2BH)...................................................................................................................171

5.59 VendorSpecific (34H) .............................................................................................................172

5.60 WriteMemory (24H) ...............................................................................................................173

6. Service Codes _______________________________________ 175

7. Event Cod es _________________________________________ 179

8. Retu rn Codes ________________________________________ 183

9. Bindings ____________________________________________ 185

9.1 Overview ....................................................................................................................................185

9.2 Presence Detection ....................................................................................................................185

9.3 Making Card Services Requests ..............................................................................................185

9.4 Argu ment Passing .....................................................................................................................186

9.5 Bind ing Specific Arguments and Services .............................................................................186

9.6 Clien t Callback Han dler ...........................................................................................................187

9.7 x86 Architectu re Bind ings ........................................................................................................187

9.7.1 DOS Real Mod e Clients ................................................................................................................................. 188

9.7.1.1 Presen ce Detection ............................................................................................................................. 188

9.7.1.2 Mak ing Car d Services Requ ests ....................................................................................................... 188

9.7.1.3 Argu ment Passing .............................................................................................................................. 188

9.7.1.4 Bind ing Specific Argu ments and Services ......................................................................................189

9.7.1.5 Clien t Callback Han dler .................................................................................................................... 1919.7.2 OS/ 2 16-bit Pro tect Mode Clien ts ................................................................................................................ 192

9.7.2.1 Presen ce Detection ............................................................................................................................. 192

9.7.2.2 Mak ing Car d Services Requ ests ....................................................................................................... 192


9.7.2.4 Bind ing Specific Argu ments and Services ......................................................................................193

9.7.2.5 Clien t Callback Han dler .................................................................................................................... 195

9.7.3 Window s 16-bit Pro tect Mode Clients ......................................................................................................... 196


8/240

CONTENTS

viii 2001 PCMCIA/JEITA

9.7.3.1 Presence Detection ............................................................................................................................. 196

9.7.3.2 Mak ing Card Services Requ ests ....................................................................................................... 196


9.7.3.4 Bind ing Specific Argu ments and Serv ices ...................................................................................... 197

9.7.3.5 Clien t Callback Handler .................................................................................................................... 199

9.7.4 Window s Flat 32-bit Protect Mod e VxD Clients ........................................................................................ 200






9.7.5 Win32 DLL Clien ts......................................................................................................................................... 204






9.7.6 Window s NT 4.0 Kernel Mod e Clients ....................................................................................................... 207






9.7.6.6 Med ia Access Table and MTD Help er Access ................................................................................ 211

10. MTD H elp er Service Referen ce _____________________ 213

10.1 MTDModifyWindow (00H) ..................................................................................................21310.2 MTDReleaseWindow (01H) ..................................................................................................214

10.3 MTDRequestWindow (02H) .................................................................................................214

10.4 MTDSetVpp (03H)..................................................................................................................215

10.5 MTDRDYMask (04H).............................................................................................................215

11. Med ia Access Services Referen ce ___________________ 217

11.1 Card SetAd dress......................................................................................................................217

11.2 Card SetAu toIn c ......................................................................................................................218

11.3 CardRead (Byte, Word, ByteAI, WordAI) ...........................................................................218

11.4 CardRead (Word s, WordsAI) ................................................................................................218

11.5 CardWrite(Byte, Word, ByteAI, WordAI) ..........................................................................219

11.6 CardWrite(Words, WordsAI) ...............................................................................................219

11.7 Card Com pare(Byte, ByteAI).................................................................................................220


9/240


2001 PCMCIA/JEITA ix

11.8 CardCom pare(Words, WordsAI) ........................................................................................220

12. Argumen t Usage Referen ce _________________________ 221

13. Clien t Callback Argu men t Usage ____________________ 223

14. OS Critical Section H an dlin g _______________________ 225


10/240


11/240


2001 PCMCIA/JEITA xi

FIGURESFigure 3-1: Software Architecture Diagram...............................................................................5

Figure 3-2: Card Services Diagram ...........................................................................................10


12/240


13/240


2001 PCMCIA/JEITA xiii

TABLESTable 61 Service Cod es (by service) ......................................................................................175

Table 62 Service Codes (sorted alphabetically)...................................................................176

Table 63 Service Cod es (sor ted n umerically) ......................................................................177

Table 71 Even t Codes (sorted alphabet ically) .....................................................................179

Table 72 Event Codes (sorted numerically).........................................................................180

Table 81 Retu rn Cod es (sorted alphabetically) ...................................................................183

Table 82 Return Codes (sorted numerically).......................................................................184


14/240


15/240


2001 PCMCIA/JEITA 1

1. INTRODUCTION

1.1 PurposeThis documen t describes the interface provided by Card Services wh ich allows PC Cards and sockets

to be sha red by m ultiple clients. (See 3.1.1Hardware Layer (PC Cards, Sockets and Adapters).) Clients

are the p rogram s that access Card Services and may be device drivers, configuration u tilities or

application programs. This specification is intended to be independent of the hardware that actually

manipu lates PC Cards an d sockets.

1.2 ScopeThis d ocum ent is intended to provide enough information for software d evelopers to

a) create a Card Services implementation on a host computer, and

b) create programs that access and use PC Cards and sockets in a host computer.

1.3 Related DocumentsThis section identifies d ocumen ts related to th e Card Services Interface Specification. Information

available in the following documents is not duplicated within this document.

PC Card Standard Release 8.0 (April 2001), PCMCIA / JEITA

Volum e 1. Ov erview and Glossary

Volum e 2.Elect rical Specif ica t ion

Volum e 3. Physical Specification

Volum e 4.Metaform at Specif ica t ion

Volum e 5. Card Servi ces Specificat ionVolum e 6. Socket Services Specificat ion

Volum e 7. PC Card A TA Specification

Volum e 8. PC Card Host Syst ems Specification

Volum e 9. Guidelines

Volume 10.Media S t orage Format s Speci fi cat ion

Volume 11.XIP Specif ica t ion

IBM-AT Technical Reference Manual, First Edition, March 1984, International Business Machines.


16/240

INTRODUCTION

2 2001 PCMCIA/JEITA

This Page Intentionally Left Blank


17/240


2001 PCMCIA/JEITA 3

2. OVERVIEW

Card Services has two goals. First, to sup port th e ability of PC Card-aw are device d rivers,

configur ation utilities, and ap plication p rogram s (known as clients) to share PC Card s, sockets, and

system resour ces. Second, to pr ovide a centralized resou rce for the comm on functionality required by

these clients.

The Card Services interface is structu red in a client/ server mod el. Application pr ogram s, device

d rivers, and u tility prog ram s are the clients requesting services. Card Services is the server p roviding

the services requested by clients. The Card Service interface specified in th is docum ent d efines how

the clients and server commu nicate.

Note: Throughout the remainder of this document clients may be referred to as

client device drivers w ithout sp ecifically m entioning ap plication an d u tility

prog ram s. This does not mean th at only device drivers can use Card Services.

Card Services may be u sed by any resident or tran sient program that

observes the interface protocol defined in this specification.

This docum ent is divided into several sections:

Chap ter 3 is a functional d escription of the Card Services interface. The overa ll architecture is

discussed w ith special focus on the prog ram ming interface, service groupings, callback interfaces,

repor ted events, Memory Technology Drivers, and how Card Services processes the Card

Information Structure.

Chap ter 4 identifies several assump tions and constra ints which app ly globally to the Card

Services interface. The reader sh ould keep these p oints in mind while reviewing o ther sections of

the specification.

Chap ter 5 discusses each of the services pr ovided by Card Services in d etail. The pu rpose of each

service is described w ith its inpu t and outpu t param eters.

The app end ices contain the following:

Service Codes

Event Codes

Return Codes

Bindings

MTD Helper Services

Med ia Access Services

Argument Usage Reference

Client Callback Argu ment Usage OS Critical Section H and ling


18/240

OVERVIEW

4 2001 PCMCIA/JEITA

This Page Intentionally Left Blank


19/240


2001 PCMCIA/JEITA 5

3. FUNCTIONAL DESCRIPTION

3.1 ArchitectureSafely using PC Card s and sockets in a n on-conflicting man ner involves the interaction of several

hard ware and software architectural layers.

Application

Resource

Management

TableMemory

Technology

Driver

Card Services

Socket Services

Adapter

PC

CardPC

Card

Operating System

Client

Figure 3-1: Software Architecture Diagram

3.1.1 Hardware Layer (PC Cards, Sockets and Adapters)

Cards compliant with the PC Card Standard are referred to as PC Cards. Originally the standard

specified data storage or mem ory cards. Later releases of the stand ard expand ed the d efinition of PC

Cards to includ e peripheral expansion or I/ O cards, provided for add itional tuples, and further

refined the software interface. This release specifies 3.3 volt operation, stand ard mu ltiple function PC

Card s and a 32-bit interface for all types of PC Card s.

All PC Card s have the sam e ph ysical characteristics and compatible electrical characteristics.

PC Cards are plugged into sockets on a host system. Host systems may have one or more sockets and

these sockets may be group ed together on one or more ad apters. An example of a host system w ith

more than one adap ter would be one where an ad apter was built into the motherboard and an other

plugged into the systems expansion bus.


20/240

FUNCTIONAL DESCRIPTION

6 2001 PCMCIA/JEITA

Adap ters usually generate maskable hardw are interrupts w hen status changes occur in sockets or on

PC Cards. Status changes includ e:

card inserted or removed,

battery low or d ead,

ejection or insertion request,

card locked or unlocked in socket, and

a busy to ready transition.

3.1.2 Socket Services

Immediately above the hardware layer the Socket Services software provides a standardized interface

to man ipulate PC Card s, sockets, and adap ters. (See the Socket Services Specificat ion.)

As noted above, host systems may have m ore than one PC Card ad apter present. Each adapter m ay

have its own Socket Services handler. All instances of Socket Services are intended to sup por t a single

instance of Card Services. Card Services registers to receive notification of statu s changes on PC

Card s or in sockets.

By m aking a ll accesses to ad ap ters, sockets, and PC Card s throu gh th e Socket Services interface,

higher-level software (includ ing Card Services) is unaffected by d ifferent implemen tations of the

hard ware. Only a hardware-specific Socket Services imp lementation mu st be modified to

accommod ate any d ifferent hard ware implementations.

3.1.3 Card Services

Above th e Socket Services software layer is the Card Services layer. Card Services coord inates access

to PC Card s, sockets and system resou rces among m ultiple clients. These clients may be resident or

transient d evice dr ivers, system utilities, or app lication p rogram s. There is only one Car d Services

implem entation in a h ost system. (Unlike Socket Services wh ere there m ay be m ultiple

implementations to accommod ate m ultiple ad apters).

Card Services makes all access to the hard ware layer throu gh th e Socket Services software interface.

The single Card Services imp lementation is intended to be th e sole client of all Socket Services

implem entations p resent. All Socket Services status chan ge repor ting is routed to this single Card

Services imp lementation. Card Services then notifies interested clients w hen statu s changes occur.

To preven t conflicts with clients who are u naw are of Card Services, direct access to the Socket

Services interface is blocked by Card Services. A m ethod of bypassing the Card Services blockage is

prov ided for softwa re developers of specialized ap plications w hich mu st access Socket Services.

Program s wh ich byp ass Card Services and make d irect access to Socket Services mu st ensure su ch

access is benign and does n ot interfere with Card Services usage of Socket Services, PC Card s,

sockets, or adapters.

Card Services preserves for its clients an abstract, socket-hard ware-imp lementation independen t

view of a card and its resour ces. Card Services presen ts the same tup le organizational and resou rce

allocation view to all of its clients w hether th e card is a 16-bit PC Card or a Card Bus PC Card .

3.1.4 Memory Technology Drivers

The PC Card Standard supp orts a wide range of memory d evices on PC Cards. While all PC Cards

containing any su ch memor y device may be read as if they contained static-RAM devices, special


21/240


2001 PCMCIA/JEITA 7

programm ing algorithms m ay be requ ired to wr ite or erase the memory devices. Card Services hides

the details of what is required to w rite or erase mem ory dev ices from client device d rivers through

byte-oriented w rite and copy services and a block-oriented er ase service.

Within Card Services, Memory Technology Dr ivers (MTD) implement th e specific program ming

algorithms required to access memory devices. These drivers may be embedded within Card Services

or may register with a Card Services imp lementation at ru n-time. When PC Cards are installed,MTDs monitoring insertion events register with Card Services to sup port access to a memory d evice

region throu gh the Card Services read , write, copy, and erase services.

Card Services provides default MTDs for recognized regions. If Card Services recognizes a region as

being composed of Static RAM devices, it installs a default MTD that sup ports read and wr ite

requests. Reads and writes are performed as simple memory accesses without any algorithmic

opera tion. If Card Services recognizes a m emory r egion but n ot the typ e of devices in the r egion, it

installs a default MTD that sup ports read and write requests and fails erase requests. The read s and

writes are performed as simp le memory accesses withou t any algorithm ic opera tion. Card Services

may includ e MTD sup port for other device types tha t require specific prog ram ming algorithm s. (See

3.6 Mem ory Technology Driv ersand see alsoAppendix -E, 10. M TD Hel per Service R eference.)

3.1.5 Client Device Drivers

Client d evice drivers refers to all users of Card Services. These may be d evice drivers, utility

programs, or app lication programs.

3.2 Programming Interface

3.2.1 Calling Conventions

The Card Services interface uses a comm on set of conventions for all services.

3.2.1.1 Basic Operation

Card Services is invoked in a p rocessor and Operating System d epend ent man ner called a bind ing.

(SeeAppendix -D, 9. Bindi ngs.)

All argum ents for Card Services requests are pa ssed in bind ing specific fashions. Card Services

defines six generic argum ents:

Service Status

Handle Argument Length

Pointer Argument Pointer

Many Car d Services requests pass all data in the Service,Handle and Pointerarguments. For such

services, no argumen t packet (as referenced by ArgPointer below) is required. If a request requ iresmore than these generic arguments, an argument packet must be used. Status of the Card Services

request is return ed in the Status ar gum ent. Using functional notation, a generic Card Services call is

as follows:

status = CardServices(Service, Handle, Pointer, ArgLength, ArgPointer)

All requests pass th e service code of the request in the Service argum ent. Individu al services and

their service field values ar e described in later sections. Many requ ests require a Card Services hand le


22/240


8 2001 PCMCIA/JEITA

to identify some resource. These requests pass the handle in the Handle argum ent. Some requ ests

require an ad ditional pointer value w hich is passed in the Pointerargument.

Many Card Services requests have an ad ditional argum ent packet wh ich is pointed to by ArgPointer.

The length of the argu ment p acket is passed in theArgLengt h argument. If theArgLengt h argum ent is

zero, there is no argument p acket and the value of theArgPointerargum ent is undefined.

TheArgLengt h argum ent may be used by a Card Services implementation to validate that theargu ment packet is app ropr iate for the indicated service. In d ifferent releases of this specification, the

appropriate length of the argument packet may vary. Card Services uses this field to determine which

packet length, and by extension, which version of the packet is being used by the client requ esting the

service.

See alsoAppendix -D, 9. Bindings for specific processor bindings for the generic Card Services

arguments.

3.2.1.2 Argument Packet

Most argum ent packets are a fixed size determined by the par ticular service as implem ented for a

par ticular p ublication of this specification. Some ar gum ent packets can be variable in length. The size

of these variable packets is determ ined by th e caller. Variable length p ackets are used to contain d ata

set by Card Services, for examp le, the Vendor Name ASCII string used to identify a particular version

of Card Services.

TheArgLengt h argu ment ind icates the length of the total packet. For variable length ar gum ent

packets, there are add itional fields in the packet that ind icate the maximum length of the variable

portion (set by the caller) and th e actual length of the return ed d ata (set by Card Services). Also some

requests have more than one variable length a rgu ment. In this case, there is also an offset field that

indicates where each add itional variable length field begins.

The specific content of an argu ment p acket is defined for each requ est that requires an argu men t

packet.

3.2.1.3 Logical Sockets

The Card Services interface, except for MapPhySocket, uses logical sockets in identifying the socket a

service is intend ed to addr ess. The first physical socket on the first ph ysical adapter is logical socket

zero (0). The maximum logical socket is the total num ber of sockets present minu s one.

3.2.1.4 Reserved Fields

Reserved fields and un defined bits shall be reset to zero before invoking a service because futu re

releases of Card Services may d efine them . Future releases will use the reset valu e for behavior

compliant w ith this release of Card Services.

Any reserved fields or undefined bits in fields return ed by Card Services are reset to zero by Card

Services so futu re releases of Card Services will be able to notify clients in a man ner comp liant withthis release.

3.2.1.5 Multi-Byte Fields

All multi-byte fields ar e stored in bind ing specific format. Multi-byte data retu rned in bulk from a PC

Card is kept in little-end ian format w ith the least significant byte ap pear ing first in mem ory. For


23/240


2001 PCMCIA/JEITA 9

example, the GetTupleData and Read/Write/CopyMemory requests transfer the data w ithout any

byte swap ping p rocessing.

(See alsoAppendix-D, 9. Bindi ngs.)

3.2.1.6 Multiple Function PC Cards

Some PC Cards may contain multiple functions. To add ress a particular function on a PC Card, the

client pa sses a card function number in the logical socket field of the app ropr iate request. Card

Functions are nu mbered from zero to one less than the num ber of functions on the PC Card.

3.2.2 Presence Detection

The Card Services GetCardServicesInfo service is used to determ ine the p resence of Card Services. If

this request fails, Card Services is not p resent. If it succeeds, Card Services is pr esent.

3.2.3 Initialization of Card Services

Card Services is designed to be implemen ted as an Op erating System Depend ent Device Driver or OSextension. If a processor supp orts different m odes of operation, Card Services can assume tha t it is

used in only a single mode. For example, processors in x86 architecture systems can run in Real Mode

or Protect Mode. Card Services can assum e that it is only used in one of these mod es at any time.

Dur ing initialization, Card Services determ ines the state of the host env ironmen t. This includ es

determ ining available system mem ory, available I/ O ports, IRQ assignments, installed PC Card s, and

socket states.

Initialization is implemen tation specific.

After Ca rd Services initializes, all Socket Services requests (080H through 0AEH) are blocked. Card

Services returns an UNSUPPORTED_SERVICE error if any attemp t is mad e to u se these services. This

pr events Socket Services clients w ho are u naw are of the Card Services interface from crash ing the

system by m aking d irect access to hard ware throu gh Socket Services. Such crashes could be causedby changing hardware state without Card Services being aware of the change. Should a Card Services

aw are client still require access to Socket Services, it may d o so by u sing the entry point r eturn ed by

the ReturnSSEntry service.

Dur ing initialization, Card Services determines a ll Socket Services imp lementations p resent so that it

can manage the status change interrupt handling required for adapters. Socket Services status events

are enabled based on client event m asks. If no clients request an event, Card Services does not need to

enable the event. Card Services records the even t wh en it occurs an d n otifies any clients who h ave

registered for its status change event and who have u nmasked the event specified.

Card Services notifies registered clients and M emory Technology Drivers wh en events requ iring

callback notification have occurred . Notification is delayed un til Card Services is in an enterable state

which allows callback handlers registered with Card Services to make requests during event

notification so they may reconfigure immed iately to react to the event.

3.2.4 Return Codes

Card Services ind icates success or failure of a request with th e generic Status a rgumen t. If the Status

argu men t is set to a non-zero value on return from a Card Services request, the request failed and the

value in the Status argumen t describes why the requ est failed. If the Status argum ent is reset to zero


24/240


10 2001 PCMCIA/JEITA

on retu rn from a Car d Services request, the request succeeded . (SeeAppendix -C, 8. Return Codes an d

see alsoAppendix-D, 9. Bindi ngs.)

3.3 Service Groups

The Card Services interface may be d ivided into five functional group s:Client Services provides for Client initialization and the callback registration of

Clients.

Resource Management provides basic access to available system resources, combiningknowledge of the current status of system resources with theunderlying Socket Services adapter control services.

Client Utilities perform common tasks required by clients so that operations suchas basic CIS tuple processing do not need to be duplicated in eachof the client device drivers.

Bulk Memory Services provides read, write, copy and erase memory services for use byfile systems or other generic memory cl ients that want to beisolated from memory technology hardware details.

Advanced Client Services provide specific services for clients with special needs.

Client Bulk Memory Client

Client Services Client Utilities

Resource Management

Advanced

Client Services Bulk Memory Services

Resource

Management

Table

Memory

Technology

Driver

Card Services

Socket Services

Adapter

PC

CardPC

Card

Figure 3-2: Card Services Diagram

3.3.1 Client Services

There are two types of services in the Client Services group:

those that su pp ort client registration with Card Services to allow event notifications, and


25/240


2001 PCMCIA/JEITA 11

those that p rovide basic inqu iry of PC Cards.

3.3.1.1 Client Registration

Card Services keeps track of the clients that can m anipulate PC Card s with Client Services. The

GetCardServicesInfo service is used by a client to determ ine the p resence of Card Services. Clients

invoke the RegisterClient service to inform Car d Services of their p resence and their interests in

various even ts. The DeregisterClient service is used wh en a client is remov ing itself from the system.

A client sp ecifies via RegisterClient wh ether it is a memory or I/ O client device driver or a Memory

Technology Dr iver. It does th is by setting the app rop riate bits in the Attributes field of the

RegisterClient request.

Clients are notified of events of interest in an ord er dep end ent on the type of client and th e order of

registration. I/ O clients are notified of PC Card insertion events first, and the last I/ O client

registered is notified first. This order allows the m ost up -to-da te I/ O client, wh ich w as the last to

register, to configure the PC Card .

Memory Technology Drivers are notified next in the ord er of registration. This order allows more u p-

to-date MTDs to rep lace MTDs that p reviously registered for a region of a PC Ca rd since all installed

MTDs can register. Notifying MTDs after I/ O clients allows the I/ O client to configur e the PC Card

and interface before an MTD starts accessing memory r egions. MTDs are assum ed to be u naffected by

the selected PC Card configur ation.

Finally, memory clients are notified in the ord er of registration. This allows mem ory clients to make

use of the PC Card in the appr opriate configur ation and also to make u se of MTDs that are already in

place to provid e access to their memory ar eas.

Clients can u se RegisterClient to be notified of events for all sockets in a system.

RequestSocketMaskcan be used if a client only w ants to be informed of events for a pa rticular

socket. Get/SetEventMaskare used to change the event mask for the client.

When a client registers for callbacks, one of the fields in the argumen t packet pr ovided is an event

mask. This m ask iden tifies the events that the client will be notified of by Card Services. The mask

Card Services uses can be mod ified by a client via SetEventMaskat any time to change the events of

interest. When an even t occurs, Card Services examines th is mask. If enabled, Card Services notifies

the client of this event. If not enabled, the client is not notified of the event.

3.3.1.2 Basic Card Support

The ResetFunction service resets the specified fun ction of the PC Card in the sp ecified socket. A

hard ware reset may cause the function to lose client-specific state. Before the hard ware reset is

perform ed, Card Services generates a RESET_PHYSICAL event. After the hard ware reset, a

CARD_RESET event is genera ted by Card Services. This allows clients to restore their specific

function state. The GetStatus service return s information abou t the current statu s of a PC Card

function and socket.

3.3.2 Resource Management

Card Services maintains a table of system resour ces usable by PC Card s and sockets. Resources are

allocated to PC Cards via RequestIO/IRQ/Window services. These resources include I/ O and

mem ory ad dr ess space and IRQs. For most efficient resource utilization, resources not needed

perman ently by a client may be return ed to the resource pool by corresponding

ReleaseIO/IRQ/Window services. For example, a memory w indow used to write to a PC Cards


26/240



configu ration registers du ring card initialization can be retu rned to the resour ce pool after card

initialization is complete.

The ModifyWindow an d MapMemPage services allow a client to specify w hat p ortions of a PC

Cards memory space are m app ed into a d edicated m emory w indow. These services also allow

control of various attribu tes of accessing this memory, includ ing access speed an d m emory sp ace.

A client u ses RequestConfiguration to configur e a PC Card and socket for an I/ O electrical interfaceand a selected configuration entry. RequestIO/IRQ/Window services mu st first be u sed to allocate

any I/ O and IRQ resources to the PC Card. After a suitable configuration is defined,

RequestConfiguration is used to set the PC Card and Socket to the requested configuration.

ModifyConfiguration can be used to make m inor adjustments to a socket and PC Card configuration.

The ReleaseConfiguration service reconfigur es the PC Card and socket back to their initial memor y

only interface.

The RequestSocketMaskservice indicates that a client wishes to m onitor the PC Card in a socket.

This service allows the client to specify the events it is interested in mon itoring. The

ReleaseSocketMaskservice ind icates that a client is n o longer interested in socket event notifications.

In CardBus PC Cards, memory and I/ O map pings are governed by Base Address Registers which

are referenced w hen requesting memory and I/ O resources for the cards. For CardBus PC Cardmap pings, the following ad ditional information for each m app ing is required:

function nu mber (0-7).

Base Add ress Register num ber, a num ber from 1 to 7. Base Add ress Register 7 is always used for

expansion ROM map pings. The combination of the socket num ber, fun ction nu mber an d the Base

Addr ess Register num ber identifies the Base Add ress Register.

The following rule applies to requested mappingsthe attributes of a given mapping indicate

wh ether the mapp ing is a 16-bit PC Card or a Ca rdBus PC Card map ping. There is no d istinction

mad e between the wind ow h and les resulting from the d ifferent kinds of mapp ing, or how the

han dles may be u sed by the Card Services client.

3.3.3 Bulk Memory Services

Bulk Mem ory Services prov ide services that can be used by clients such as file system u tilities or XIP

install utilities to avoid d ealing with all the d etails of the various m emory technologies that can be

presen t on PC Cards. These services supp ort a simple Open/CloseMemory an d

Read/Write/CopyMemory mod el of memory access. This model is similar to op en, close, read, and

wr ite access to files in most op erating systems.

Card Services determines PC Card memory regions during card insertion processing. Clients may

determine areas in PC Card memory th ey wish to access by parsing the CIS or using the Card

Services services GetFirst/NextTuple, GetFirst/NextPartition , or GetFirst/NextRegion. Once a client

determ ines the area of the PC Card th ey wish to access, they use the OpenMemory request and

specify the absolute offset on the PC Car d w here the area begins.

OpenMemory returns a m emory hand le that is used for all subsequent read, w rite, copy an d erase

operations. These operations sp ecify the location to be accessed r elative to the start of the opened

memory area. This allows clients to move d ata to and from PC Card m emory as d esired w ithout

concern as to wher e on the PC Card this particular mem ory area lies. A client performs a

CloseMemory request to inform Car d Services that it will no longer be accessing a m emory ar ea.

Performing an era se operation d iffers from the read, w rite and copy services. A client that n eeds to

erase memory mu st register an erase queue with the RegisterEraseQueue request. The client then fills

an erase queu e entry identifying the socket and region of mem ory to erase. Next, the


27/240



CheckEraseQueue request is used to notify Card Services that one or m ore erase requests hav e been

made in the erase queue. The actual erase operation is performed asynchronously. When the erase

opera tion completes, the client is notified th rough the callback entry p oint prov ided in the erase

queue header. In comparison, the read, write, and copy services return only after the requested action

has been completed.

A client must use DeregisterEraseQueue to request Car d Services to relinquish control of an erasequeue. This mu st be invoked before a client is removed from m emory. DeregisterEraseQueue can

only be used w hen there are no qu eued erase requests in the erase queue.

Since erase opera tions retur n before the erase is complete, the client m ay be able to access other

services wh ile wa iting for the erase completion. The physical constru ction of some card s (or memor y

compon ents) may prevent some services un til the erase operation in prog ress has been completed. In

this event, the other requ ested op eration is blocked (delayed ) within Card Services until the erase is

completed . Card Services does not notify the requester of erase completion un til the blocked requ est

is complete.

3.3.4 Client Utilities

Card Services clients m ay need to pr ocess a PC Card s Card Information Structure (CIS) to determ ineif and h ow they w ill interact with a card d etected in a socket. (Some clients may receive all the

information they require from the CARD_INSERTION event). The Client Utilities services red uce

the code requ ired for individu al clients to perform such processing. GetFirst/NextTuple allow a

client to traverse the CIS withou t being aware of how tu ple links are evaluated . The client may

concentrate on w hat to d o w ith tuple data without h aving to du plicate the link traversal code. The

client retrieves the contents of the tup le by using GetTupleData . Since many clients also require

information d escribing regions and partitions d erived from mu ltiple tup les, GetFirst/NextRegion

an d GetFirst/NextPartition services are included to pr ovide sp ecific informa tion withou t a client

having an y know ledge of the specific tuples containing the necessary da ta.

Clients shou ld be aware that tuples may change between calls to any of the tuple processing services.

Tup les could be changed by other clients (such as formatting u tilities) that w rite tuples.

RequestExclusive can be used to p revent other clients from accessing the PC Card d uring tu plemodification.

3.3.5 Advanced Client Services

Ad vanced Client Services prov ides a m iscellaneou s set of services for u se by client d evice d rivers

with special needs. ReturnSSEntry pr ovides d irect access to Socket Services. Clients that need direct

Socket Services access can use this service to retrieve a reference to the location containing the Socket

Services entry point. The MapLogSocket/Window and MapPhySocket/Window services have been

pr ovided to use the Socket Services interface on physical adap ter hard ware that has been allocated

logically to a client by Card Services.

W A R N I N G

Even though direct access t o Socket Services is possible, such access may cause

resource management services in Card Services to lose synchronization resulting

in degraded operation, system crashes, or even hardware damage. Clients

directly accessing Socket Services are responsible to ensure their usage does not

int erfere with Card Services.


28/240



Some advan ced PC Card u tilities may wan t to browse information p resent in Card Services to inform

the end user of what is present in the host system. GetFirst/NextClient an d GetClientInfo are

provided to return information about clients registered with Card Services.

SetRegion can be used to d efine a memory region that an MTD can supp ort when Card Services

doesn t au tomatically recognize the region.

RegisterTimer allows a client to be called back after the specified d elay. The actual callback is onlyperform ed w hen Car d Services is enterable. This may result in a longer delay than sp ecified.

Request/ReleaseExclusive allow a client to ga in exclusive access to a PC Card . This could be used to

allow a u tility that writes or upd ates the CIS to have safe access to a PC Card.

ValidateCIS can be u sed to check the validity of the tu ple chains in the CIS.

AddSocketServices allows add itional driver versions of Socket Services to be add ed to an already

initialized Card Services. ReplaceSocketServices allows a different and poten tially newer version of

Socket Services to replace an existing ver sion. In ad dition, these services are used d ur ing dock-events

by socket services hand lers that are ad ding, changing or removing supp ort for add ed or removed

socket controllers.

3.4 Callback InterfacesCard Services notifies clients of a ll events th rough a single callback interface. A client ma y be called

back for any of the d efined events. Except for CARD_INSERTION events, clients are not guarant eed

to be notified in any par ticular ord er for a specific event. A client m ay be notified of any even t at any

time. Some events are sequ enced in relation to other events. For example, Card Services notifies all

clients ofRESET_REQUEST before any client is notified ofRESET_PHYSICAL. Specific event

sequencing is d efined in Section 3.5:Events.

Each event passes information to the client callback hand ler based on the type of event. Each type of

event and th e arguments it pa sses is discussed in the following sections. A client can make Card

Services requests during callback pr ocessing.

Generic argum ent descriptions are u sed to d efine the information th at is passed to the clientscallback handler. Appendix H defines the processor specific arguments used. The generic arguments

are:

Service Buffer

Socket Misc

Info Status

MTDRequest ClientData

Using fun ctional n otation, a Car d Services callback is as follows:

Status = Callback(Service, Socket, Info, MTDRequest, Buffer, Misc,

ClientData)

For all events, the Service argu men t contains a value iden tifying the event on entry to the clients

callback hand ler. These event values are d efined so that a single callback procedure can han dle all

types of events. The ClientData argum ent passes the information from the RegisterClient services

ClientData field.

The Socketargu ment id entifies the socket and function affected by th e event. For PC Cards with

independently controllable functions the upper portion of the Socketargum ent is the function nu mber

(ranging from zero to one less than the number of functions on the card ). TheInfo argum ent contains


29/240



other information sp ecific to the event being reported . The Status argument is used by callback

hand lers to retur n information to Card Services. TheBufferargum ent is used to p ass a pointer to a

bu ffer for m odification by the client. TheMisc argument is used for miscellaneous information.

TheMTDRequestis used specifically by MTDs to sup por t read , write, copy, and era se requests.

A client event hand ler must p reserve all callback entry argu men ts unless otherwise indicated. This

ensu res other callback hand lers receive the same informa tion and that Card Services may rely on theinformation when all handlers have completed p rocessing so it may perform any ad ditional

processing required.

Card Services sends separate notifications for each function on a m ultiple function PC Card.

3.4.1 Insertion

The Service, Socket, and ClientData argu men ts are passed to the client callback hand ler for a

CARD_INSERTION event.

A client registers for insertion even ts with th e RegisterClient service. Once registered, the client is

notified each time a PC Car d is inserted into a socket.

As part of the RegisterClient request, the client specifies interest in a rtificial insertion events for PC

Card s inserted in sockets before the client registered. These artificial insertion events ar e intend ed to

allow a client to establish its initial interna l state withou t having to poll sockets to determine w hether

PC Card s are installed. Artificial insertion events are generated only once when a client first registers.

Previously registered clients w ho have alread y completed initialization do not receive these artificial

insertion events.

Since not all sockets may contain PC Card s and Card Services only sends a rtificial insertion even ts for

occup ied sockets, a client needs to determ ine when a ll such events have been generated . For this

reason, Card Services generates a special REGISTRATION_COMPLETE event d irectly to the

requester after all artificial insertion even ts have been sent.

3.4.2 Registration CompletionThe Service an d ClientData argu men ts are passed to the client callback hand ler for the

REGISTRATION_COMPLETE event.

When a RegisterClient request is made, Card Services saves the client registration information and

immed iately returns to the client. Card Services then attemp ts to perform the registration in the

background . When the registration p rocessing is completed, Card Services notifies the requesting

clients callback hand ler with a REGISTRATION_COMPLETE event.

3.4.3 Status Change

The Service, Socketand ClientData argu ments are p assed to the client callback hand ler for the

following even ts:

BATTERY_LOW BATTERY_DEAD

CARD_LOCK CARD_UNLOCK

CARD_READY CARD_REMOVAL

PM_SUSPEND PM_RESUME

REQUEST_ATTENTION WRITE_PROTECT


30/240



A client can receive events for any socket if it has enabled the event in its global event m ask which is

initially set by a client call to RegisterClient . The global event m ask can also be set by SetEventMask.

To receive sp ecific event n otifications for the socket, a client can also p erform an op tional

RequestSocketMaskcall before d irectly accessing a PC Card in a socket. A RequestSocketMaskis

useful since it allows a client to be notified of events for a specific socket. IfRequestSocketMaskis

successful, the client receives events for the specified socket. Once installed, the clients callbackhan dler is notified of statu s change events for the socket or PC Car d installed in the socket. Clients

may d ynam ically specify wh ich status change events they are interested in by using the

SetEventMaskservice.

If the PC Card in the socket experiencing the statu s change has m ultiple functions and the change is

specific to a single function, the function number is p laced in the u pp er half of the Socketargument.

Note: A separate event notification is sent to a client for each function on a PC

Card.

3.4.4 Ejection/Insertion Requests

The Service, Socket, and ClientData argu ments are p assed to the client callback hand ler for the

following even ts:

EJECTION_REQUEST EJECTION_COMPLETE

INSERTION_REQUEST INSERTION_COMPLETE

For the _REQUEST events, the Status argu men t mu st be set to SUCCESS on return to Ca rd Services

indicating that the client handled th e request. If the Status argu ment is not set to SUCCESS, the

request is rejected and the ejection or insertion w ill not be p erformed .

Note: The EJECTION_REQUEST , EJECTION_COMPLETE ,

INSERTION_REQUEST, and INSERTION_COMPLETE events refer to

states related to d riving a m otor to insert or remove a PC Card and are not

the same as the CARD_INSERTION or CARD_REMOVAL events

described in oth er sections.

3.4.5 Exclusive

The Service, Socket, and ClientData argu ments are p assed to the client callback hand ler for the

following even ts:

EXCLUSIVE_REQUEST EXCLUSIVE_COMPLETE

When a RequestExclusive request is mad e to Card Services, it saves any information need ed an d

immed iately returns to the client. Card Services then attemp ts to make the PC Card available for

exclusive use of the requesting client. For the EXCLUSIVE _REQUEST event, th e Status argument

mu st be set to SUCCESS on retu rn to Card Services to ind icate the client ap prov es the requ est. If theStatus argu men t is not set to SUCCESS, the requ est is rejected and the exclusive access will not be

allowed.

When the exclusive processing is completed , Card Services notifies the requ esting client a t its callback

entry with an EXCLUSIVE_COMPLETE event. If the EXCLUSIVE_REQUEST was rejected,

EXCLUSIVE_COMPLETE is sent to the requ esting client and theInfo argum ent is set to the return

code set by the client that rejected th e request.


31/240



3.4.6 Reset

The Service, Socket, and ClientData argu men ts are passed to the client callback hand ler for the

following even ts:

RESET_REQUEST RESET_PHYSICAL

CARD_RESET RESET_COMPLETE

When a ResetFunction request is mad e to Card Services, it notes that a reset has been requ ested and

retur ns from the requ est. When the reset processing has been completed, Card Services notifies the

clients callback hand ler with a RESET_COMPLETE event. If the RESET_REQUEST was rejected,

RESET_COMPLETE is sent to the requ esting client and theInfo argum ent is set to the return code set

by the client that rejected th e request.

3.4.7 Client Information

The Service an d ClientData argu men ts are passed to the client callback hand ler for the following

events:

CLIENT_INFO

TheBufferargum ent is passed for the CLIENT_INFO callback and points to a da ta bu ffer to be filled

with information by the client.

See the Service Reference for GetClientInfo for the format of the data bu ffer wh en the up per byte of

theA tt ributes field is zero (0).

3.4.8 Erase Completion

The ERASE_COMPLETE event passes Service, Socket, and ClientData argu ments to th e client callback

hand ler. TheInfo argum ent contains the erase queue entry nu mber. TheMisc argum ent contains the

QueueHandle.

When an erase oper ation is requested of Card Services either via RegisterEraseQueue or

CheckEraseQueue, Card Services only notes that there is new information in the erase queue and

returns from the request. When an erase operation completes after having been processed in the

background , the client callback hand ler specified in the erase queu e head er is notified of the

ERASE_COMPLETE event.

3.4.9 MTD Request

The MTD_REQUEST event passes Service,Buffer,MTDRequest, Socketand ClientData argum ents to

the client callback handler. (See3.6 Memory Technology Drivers.)

3.4.10 Timer

The TIMER_EXPIRED event pa sses Service,Misc and ClientData argu ments to the client callback

hand ler. TheMisc argum ent contains the timer hand le returned by RegisterTimer.


32/240



3.4.11 New or Removed Socket Services

The SS_UPDATED event passes the Service, Socket, ClientData, and Info argu ments to the client

callback han dler. The Socketargu ment contains the logical socket num ber of the first socket sup ported

by the n ewly installed Socket Services hand ler.

TheInfo argum ent is bit map ped as follows:Bits 0 7 Number of sockets affected

Bit 8..9 New Sockets (bit mapped)

00 = PreviousReplaced01 = SocketsAdded10 = SocketsRemoved11 = SocketRenumber

Bits 10 15 RESERVED (reset to zero)

The New Sockets field is bit mapp ed field w here the value identifies wh at event has occurr ed. The

value of zero (0) signals that th e previously installed Socket Services handler w as replaced. The value

one (1) signals that add itional sockets are present in the system an d a n ew socket services hand ler is

handling them. The value two (2) signals that sockets wer e removed from the system and that thesocket services hand ler is no longer han dling them . The value three (3) signals that the sockets are

renumbering.

When th e New Sockets field is three (3) then the MISCparameter will contain the new socket

hand le/ num ber for the affected socket.


33/240


34/240



3.5.1 BATTERY_DEAD

Callback(BATTERY_DEAD, Socket, 0, null, null, 0, ClientData)

The BATTERY_DEAD event indicates the battery on a PC Card is no longer providing operational

voltage.

Cause The BATTERY_DEAD event occurs when the BVD1 signal on a PC Card is negated. This signalmay be available at the socket interface or in the pin replacement register. The negation of thissignal results in a status change interrupt.

Pre-Client Card Services notes a transition to a BATTERY_DEAD state. When the Card Services interfaceis available, Card Services notifies clients who have indicated their interest in BATTERY_DEADevents.

Client A client processing BATTERY_DEAD notifications might warn the end-user that the PC Card isno longer capable of safely storing data if the PC Card is removed. How the client interacts withthe end-user or what data loss preventive measures are taken is implementation specific.

Post-Client Card Services does not perform any additional processing after notifying clients using the socketof the BATTERY_DEAD event.

Note: If the battery on a PC Card is dead when it is inserted, no BATTERY_DEADevent is generated. A BATTERY_DEAD event is only generated wh en the

BVD1 signal is negated a fter a PC Card has been inserted w ith the BVD1

signal asserted.

See also BATTERY_LOW.


35/240



3.5.2 BATTERY_LOW

Callback(BATTERY_LOW, Socket, 0, null, null, 0, ClientData)

The BATTERY_LOW event ind icates the battery on a PC Card is weak and is in need of replacement.

Cause The BATTERY_LOW event occurs when the BVD2 signal on a PC Card is negated. This signalmay be available at the socket interface or in the pin replacement register. The negation of thissignal results in a status change interrupt.

Pre-Client Card Services notes a transition to a BATTERY_LOW state. When the Card Services interface isavailable, Card Services notifies clients who have indicated their interest in BATTERY_LOWevents.

Client A client processing BATTERY_LOW notifications might warn the end-user that the PC Cardbattery needs replacement. How the client interacts with the end-user or what data losspreventive measures are taken is implementation specific.

Post-Client Card Services does not perform any additional processing after notifying clients using the socketof the BATTERY_LOW event.

Note: If the battery is weak on a PC Card when it is inserted, no BATTERY_LOW

event is generated. A BATTERY_LOW event is only generated wh en theBVD2 signal is negated after a PC Card has been inserted with the BVD2

signal asserted.

See also BATTERY_DEAD .


36/240



3.5.3 CARD_INSERTION

Callback(CARD_INSERTION, Socket, 0, null, null, ClientHandle,

ClientData)

The CARD_INSERTION event ind icates a PC Card has been inserted in a socket or Card Services iscreating artificial insertion events for PC Card s already in sockets. A sepa rate CARD_INSERTION is

generated for each function on a mu ltiple function PC Card.

Cause The CARD_INSERTION event occurs when the Card Detect pins (CD1# and CD2#) are assertedby the insertion of a PC Card. Card Services issues an AcknowledgeInterrupt request to SocketServices.

CARD_INSERTION events may also be artificially generated by Card Services after a new clientperforms a RegisterClient request. Artificial CARD_INSERTION events are only generated forsockets containing PC Cards. Registering clients may indicate whether they wish artificialCARD_INSERTION events for all PC Cards or only those without exclusive clients.

When an exclusive use of a PC Card is requested by RequestExclusive, a CARD_INSERTIONevent is generated

PC Card Standard 8.0 Volume 5 Card Services Specification

Documents

Transcript of PC Card Standard 8.0 Volume 5 Card Services Specification