Copyright (c) 1996, Sun Microsystems, Inc. All Rights Reserved
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
#include <sys/pccard.h> 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_RequestConfiguration(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 specified.
csx_RequestIO() fails if it has already been called without a corresponding csx_ReleaseIO().
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: Socket
Not used in Solaris, but for portability with other Card Services implementations, it should be set to the logical socket number.
BasePort1.handle
BasePort2.base
BasePort2.handle
Two I/O address ranges can be requested by csx_RequestIO(). Each I/O address range is specified 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 accessing 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 field value. If the BasePort.base field is set to 0, Card Services returns an I/O resource based on the available I/O resources and the number of contiguous ports requested. When BasePort.base is 0, Card Services aligns the returned resource in the host system'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 requested.
This field is bit-mapped. The following bits are defined: IO_DATA_WIDTH_8
I/O resource uses 8-bit data path.
I/O resource uses 16-bit data path.
Host endian byte ordering.
Big endian byte ordering
Little endian byte ordering.
Program ordering references.
May re-order references.
Merge stores to consecutive locations.
May cache load operations.
May cache store operations.
The data references must be issued by a CPU in program order. Strict ordering is the default behavior.
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 consecutive 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 re-ordering.
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.
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 BasePort, NumPorts, and/or IOAddrLines values will have to be made to find an acceptable combination of parameters that can be used by Card Services to allocate I/O resources for the client. (See NOTES).
Successful operation.
Invalid Attributes specified.
BasePort value is invalid.
Client handle is invalid.
csx_RequestConfiguration(9F) has already been done.
csx_RequestIO() has already been done without 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.
csx_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 convenient 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.