CSX_DUPHANDLE(9F) Kernel Functions for Drivers CSX_DUPHANDLE(9F)
NAME
csx_DupHandle - duplicate access handle
SYNOPSIS
#include <sys/pccard.h>
int32_t csx_DupHandle(
acc_handle_t handle1,
acc_handle_t *handle2,
uint32_t flags);
INTERFACE LEVEL
illumos
DDI Specific (illumos
DDI)PARAMETERS
handle1 The access handle returned from
csx_RequestIO(9F) or
csx_RequestWindow(9F) that is to be duplicated.
handle2 A pointer to the newly-created duplicated data access
handle.
flags The access attributes that will be applied to the new
handle.
DESCRIPTION
This function duplicates the handle,
handle1, into a new handle,
handle2, that has the access attributes specified in the
flags argument. Both the original handle and the new handle are active and
can be used with the common access functions.
Both handles must be explicitly freed when they are no longer
necessary.
The
flags argument is bit-mapped. The following bits are defined:
WIN_ACC_NEVER_SWAP Host endian byte ordering
WIN_ACC_BIG_ENDIAN Big endian byte ordering
WIN_ACC_LITTLE_ENDIAN Little endian byte ordering
WIN_ACC_STRICT_ORDER Program ordering references
WIN_ACC_UNORDERED_OK May re-order references
WIN_ACC_MERGING_OK Merge stores to consecutive locations
WIN_ACC_LOADCACHING_OK May cache load operations
WIN_ACC_STORECACHING_OK May cache store operations
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
flags bits. Only one of
the following bits may be specified:
WIN_ACC_STRICT_ORDER The data references must be issued by a
CPU in program order. Strict ordering is
the default behavior.
WIN_ACC_UNORDERED_OK 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).
WIN_ACC_MERGING_OK 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. Setting this bit
also implies re-ordering.
WIN_ACC_LOADCACHING_OK 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. Setting this bit also implies
merging and re-ordering.
WIN_ACC_STORECACHING_OK 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.
Setting this bit also implies load
caching, merging, and re-ordering.
These values are advisory, not mandatory. For example, data can be
ordered without being merged or cached, even though a driver requests
unordered, merged and cached together.
RETURN VALUES
CS_SUCCESS Successful operation.
CS_FAILURE Error in
flags argument or handle could
not be duplicated for some reason.
CS_UNSUPPORTED_FUNCTION No
PCMCIA hardware installed.
CONTEXT
This function may be called from user or kernel context.
SEE ALSO
csx_Get8(9F),
csx_GetMappedAddr(9F),
csx_Put8(9F),
csx_RepGet8(9F),
csx_RepPut8(9F),
csx_RequestIO(9F),
csx_RequestWindow(9F) PC Card 95 Standard, PCMCIA/JEIDA July 19, 1996 CSX_DUPHANDLE(9F)