csx_RequestIO, csx_ReleaseIO - request or release I/O resources for the
int32_t csx_RequestIO(client_handle_t ch, io_req_t *ir);
int32_t csx_ReleaseIO(client_handle_t ch, io_req_t *ir);
Solaris DDI Specific (Solaris DDI)
Client handle returned from csx_RegisterClient(9F).
Pointer to an io_req_t structure.
The functions csx_RequestIO() and csx_ReleaseIO() request or release,
respectively, I/O resources for the client.
If a client requires I/O resources, csx_RequestIO() must be called to
request I/O resources from Card Services; then csx_RequestConfigura‐
tion(9F) must be used to establish the configuration. csx_RequestIO()
can be called multiple times until a successful set of I/O resources is
found. csx_RequestConfiguration(9F) only uses the last configuration
csx_RequestIO() fails if it has already been called without a corre‐
csx_ReleaseIO() releases previously requested I/O resources. The Card
Services window resource list is adjusted by this function. Depending
on the adapter hardware, the I/O window might also be disabled.
The structure members of io_req_t are:
uint32_t Socket; /* socket number*/
uint32_t Baseport1.base; /* IO range base port address */
acc_handle_t Baseport1.handle; /* IO range base address
/* or port num */
uint32_t NumPorts1; /* first IO range number contiguous
/* ports */
uint32_t Attributes1; /* first IO range attributes */
uint32_t Baseport2.base; /* IO range base port address */
acc_handle_t Baseport2.handle; /* IO range base address or port num */
uint32_t NumPorts2; /* second IO range number contiguous
/* ports */
uint32_t Attributes2; /* second IO range attributes */
uint32_t IOAddrLines; /* number of IO address lines decoded */
The fields are defined as follows:
Not used in Solaris, but for portability with other
Card Services implementations, it should be set to
the logical socket number.
Two I/O address ranges can be requested by
csx_RequestIO(). Each I/O address range is speci‐
fied by the BasePort, NumPorts, and Attributes
fields. If only a single I/O range is being
requested, the NumPorts2 field must be reset to 0.
When calling csx_RequestIO(), the BasePort.base
field specifies the first port address requested.
Upon successful return from csx_RequestIO(), the
BasePort.handle field contains an access handle,
corresponding to the first byte of the allocated
I/O window, which the client must use when access‐
ing the PC Card's I/O space via the common access
functions. A client must not make any assumptions
as to the format of the returned BasePort.handle
If the BasePort.base field is set to 0, Card Ser‐
vices returns an I/O resource based on the avail‐
able I/O resources and the number of contiguous
ports requested. When BasePort.base is 0, Card Ser‐
vices aligns the returned resource in the host sys‐
tem's I/O address space on a boundary that is a
multiple of the number of contiguous ports
requested, rounded up to the nearest power of two.
For example, if a client requests two I/O ports,
the resource returned will be a multiple of two. If
a client requests five contiguous I/O ports, the
resource returned will be a multiple of eight.
If multiple ranges are being requested, at least
one of the BasePort.base fields must be non-zero.
This field is the number of contiguous ports being
This field is bit-mapped. The following bits are
I/O resource uses 8-bit
I/O resource uses 16-bit
Host endian byte order‐
Big endian byte ordering
Little endian byte
Program ordering refer‐
May re-order references.
Merge stores to consecu‐
May cache load opera‐
May cache store opera‐
For some combinations of host system busses and
adapter hardware, the width of an I/O resource can
not be set via RequestIO(); on those systems, the
host bus cycle access type determines the I/O
resource data path width on a per-cycle basis.
WIN_ACC_BIG_ENDIAN and WIN_ACC_LITTLE ENDIAN
describe the endian characteristics of the device
as big endian or little endian, respectively. Even
though most of the devices will have the same
endian characteristics as their busses, there are
examples of devices with an I/O processor that has
opposite endian characteristics of the busses.
When WIN_ACC_BIG_ENDIAN or WIN_ACC_LITTLE ENDIAN is
set, byte swapping will automatically be performed
by the system if the host machine and the device
data formats have opposite endian characteristics.
The implementation may take advantage of hardware
platform byte swapping capabilities.
When WIN_ACC_NEVER_SWAP is specified, byte swapping
will not be invoked in the data access functions.
The ability to specify the order in which the CPU
will reference data is provided by the following
Attributes bits. Only one of the following bits may
The data references must be issued by a CPU in
program order. Strict ordering is the default
The CPU may re-order the data references. This
includes all kinds of re-ordering (that is, a
load followed by a store may be replaced by a
store followed by a load).
The CPU may merge individual stores to consecu‐
tive locations. For example, the CPU may turn
two consecutive byte stores into one halfword
store. It may also batch individual loads. For
example, the CPU may turn two consecutive byte
loads into one halfword load. IO_MERGING_OK_ACC
also implies re-ordering.
The CPU may cache the data it fetches and reuse
it until another store occurs. The default
behavior is to fetch new data on every load.
WIN_ACC_LOADCACHING_OK also implies merging and
The CPU may keep the data in the cache and push
it to the device (perhaps with other data) at a
later time. The default behavior is to push the
data right away. WIN_ACC_STORECACHING_OK also
implies load caching, merging, and re-ordering.
These values are advisory, not mandatory. For exam‐
ple, data can be ordered without being merged or
cached, even though a driver requests unordered,
merged and cached together. All other bits in the
Attributes field must be set to 0.
This field is the number of I/O address lines
decoded by the PC Card in the specified socket.
On some systems, multiple calls to csx_RequestIO() with different Base‐
Port, NumPorts, and/or IOAddrLines values will have to be made to find
an acceptable combination of parameters that can be used by Card Ser‐
vices to allocate I/O resources for the client. (See NOTES).
Invalid Attributes specified.
BasePort value is invalid.
Client handle is invalid.
csx_RequestConfiguration(9F) has already
csx_RequestIO() has already been done with‐
out a corresponding csx_ReleaseIO().
No PC Card in socket.
Unable to allocate I/O resources.
Unable to allocate I/O resources.
No PCMCIA hardware installed.
These functions may be called from user or kernel context.
SEE ALSOcsx_RegisterClient(9F), csx_RequestConfiguration(9F)
PC Card 95 Standard, PCMCIA/JEIDA
It is important for clients to try to use the minimum amount of I/O
resources necessary. One way to do this is for the client to parse the
CIS of the PC Card and call csx_RequestIO() first with any IOAddrLines
values that are 0 or that specify a minimum number of address lines
necessary to decode the I/O space on the PC Card. Also, if no conve‐
nient minimum number of address lines can be used to decode the I/O
space on the PC Card, it is important to try to avoid system conflicts
with well-known architectural hardware features.
Jul 19, 1996 CSX_REQUESTIO(9F)