NAME¶
bus_space
,
bus_space_barrier
,
bus_space_copy_region_1
,
bus_space_copy_region_2
,
bus_space_copy_region_4
,
bus_space_copy_region_8
,
bus_space_copy_region_stream_1
,
bus_space_copy_region_stream_2
,
bus_space_copy_region_stream_4
,
bus_space_copy_region_stream_8
,
bus_space_free
,
bus_space_map
,
bus_space_read_1
,
bus_space_read_2
,
bus_space_read_4
,
bus_space_read_8
,
bus_space_read_multi_1
,
bus_space_read_multi_2
,
bus_space_read_multi_4
,
bus_space_read_multi_8
,
bus_space_read_multi_stream_1
,
bus_space_read_multi_stream_2
,
bus_space_read_multi_stream_4
,
bus_space_read_multi_stream_8
,
bus_space_read_region_1
,
bus_space_read_region_2
,
bus_space_read_region_4
,
bus_space_read_region_8
,
bus_space_read_region_stream_1
,
bus_space_read_region_stream_2
,
bus_space_read_region_stream_4
,
bus_space_read_region_stream_8
,
bus_space_read_stream_1
,
bus_space_read_stream_2
,
bus_space_read_stream_4
,
bus_space_read_stream_8
,
bus_space_set_multi_1
,
bus_space_set_multi_2
,
bus_space_set_multi_4
,
bus_space_set_multi_8
,
bus_space_set_multi_stream_1
,
bus_space_set_multi_stream_2
,
bus_space_set_multi_stream_4
,
bus_space_set_multi_stream_8
,
bus_space_set_region_1
,
bus_space_set_region_2
,
bus_space_set_region_4
,
bus_space_set_region_8
,
bus_space_set_region_stream_1
,
bus_space_set_region_stream_2
,
bus_space_set_region_stream_4
,
bus_space_set_region_stream_8
,
bus_space_subregion
,
bus_space_unmap
,
bus_space_write_1
,
bus_space_write_2
,
bus_space_write_4
,
bus_space_write_8
,
bus_space_write_multi_1
,
bus_space_write_multi_2
,
bus_space_write_multi_4
,
bus_space_write_multi_8
,
bus_space_write_multi_stream_1
,
bus_space_write_multi_stream_2
,
bus_space_write_multi_stream_4
,
bus_space_write_multi_stream_8
,
bus_space_write_region_1
,
bus_space_write_region_2
,
bus_space_write_region_4
,
bus_space_write_region_8
,
bus_space_write_region_stream_1
,
bus_space_write_region_stream_2
,
bus_space_write_region_stream_4
,
bus_space_write_region_stream_8
,
bus_space_write_stream_1
,
bus_space_write_stream_2
,
bus_space_write_stream_4
,
bus_space_write_stream_8
—
bus space manipulation functions
SYNOPSIS¶
#include
<machine/bus.h>
int
bus_space_map
(
bus_space_tag_t
space,
bus_addr_t address,
bus_size_t size,
int flags,
bus_space_handle_t *handlep);
void
bus_space_unmap
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t size);
int
bus_space_subregion
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
bus_size_t size,
bus_space_handle_t *nhandlep);
int
bus_space_alloc
(
bus_space_tag_t
space,
bus_addr_t reg_start,
bus_addr_t reg_end,
bus_size_t size,
bus_size_t alignment,
bus_size_t boundary,
int flags,
bus_addr_t *addrp,
bus_space_handle_t *handlep);
void
bus_space_free
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t size);
uint8_t
bus_space_read_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint16_t
bus_space_read_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint32_t
bus_space_read_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint64_t
bus_space_read_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint8_t
bus_space_read_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint16_t
bus_space_read_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint32_t
bus_space_read_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
uint64_t
bus_space_read_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset);
void
bus_space_write_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value);
void
bus_space_write_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value);
void
bus_space_write_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value);
void
bus_space_write_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value);
void
bus_space_write_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value);
void
bus_space_write_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value);
void
bus_space_write_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value);
void
bus_space_write_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value);
void
bus_space_barrier
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
bus_size_t length,
int flags);
void
bus_space_read_region_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_read_region_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_read_region_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_read_region_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_read_region_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_read_region_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_read_region_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_read_region_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_write_region_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_write_region_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_write_region_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_write_region_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_write_region_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_write_region_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_write_region_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_write_region_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_copy_region_1
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_2
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_4
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_8
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_copy_region_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t srchandle,
bus_size_t srcoffset,
bus_space_handle_t dsthandle,
bus_size_t dstoffset,
bus_size_t count);
void
bus_space_set_region_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value,
bus_size_t count);
void
bus_space_set_region_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value,
bus_size_t count);
void
bus_space_set_region_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value,
bus_size_t count);
void
bus_space_set_region_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value,
bus_size_t count);
void
bus_space_set_region_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value,
bus_size_t count);
void
bus_space_set_region_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value,
bus_size_t count);
void
bus_space_set_region_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value,
bus_size_t count);
void
bus_space_set_region_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value,
bus_size_t count);
void
bus_space_read_multi_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_read_multi_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_read_multi_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_read_multi_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_read_multi_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_read_multi_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_read_multi_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_read_multi_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_write_multi_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_write_multi_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_write_multi_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_write_multi_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_write_multi_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t *datap,
bus_size_t count);
void
bus_space_write_multi_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t *datap,
bus_size_t count);
void
bus_space_write_multi_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t *datap,
bus_size_t count);
void
bus_space_write_multi_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t *datap,
bus_size_t count);
void
bus_space_set_multi_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value,
bus_size_t count);
void
bus_space_set_multi_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value,
bus_size_t count);
void
bus_space_set_multi_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value,
bus_size_t count);
void
bus_space_set_multi_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value,
bus_size_t count);
void
bus_space_set_multi_stream_1
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint8_t value,
bus_size_t count);
void
bus_space_set_multi_stream_2
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint16_t value,
bus_size_t count);
void
bus_space_set_multi_stream_4
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint32_t value,
bus_size_t count);
void
bus_space_set_multi_stream_8
(
bus_space_tag_t
space,
bus_space_handle_t handle,
bus_size_t offset,
uint64_t value,
bus_size_t count);
DESCRIPTION¶
The
bus_space
functions exist to allow device
drivers machine-independent access to bus memory and register areas. All of
the functions and types described in this document can be used by including
the
<machine/bus.h>
header file.
Many common devices are used on multiple architectures, but are accessed
differently on each because of architectural constraints. For instance, a
device which is mapped in one system's I/O space may be mapped in memory space
on a second system. On a third system, architectural limitations might change
the way registers need to be accessed (e.g. creating a non-linear register
space). In some cases, a single driver may need to access the same type of
device in multiple ways in a single system or architecture. The goal of the
bus_space
functions is to allow a single
driver source file to manipulate a set of devices on different system
architectures, and to allow a single driver object file to manipulate a set of
devices on multiple bus types on a single architecture.
Not all busses have to implement all functions described in this document,
though that is encouraged if the operations are logically supported by the
bus. Unimplemented functions should cause compile-time errors if possible.
All of the interface definitions described in this document are shown as
function prototypes and discussed as if they were required to be functions.
Implementations are encouraged to implement prototyped (type-checked) versions
of these interfaces, but may implement them as macros if appropriate.
Machine-dependent types, variables, and functions should be marked clearly in
<machine/bus.h>
to avoid confusion with the machine-independent types and functions, and, if
possible, should be given names which make the machine-dependence clear.
CONCEPTS AND GUIDELINES¶
Bus spaces are described by bus space tags, which can be created only by
machine-dependent code. A given machine may have several different types of
bus space (e.g. memory space and I/O space), and thus may provide multiple
different bus space tags. Individual busses or devices on a machine may use
more than one bus space tag. For instance, ISA devices are given an ISA memory
space tag and an ISA I/O space tag. Architectures may have several different
tags which represent the same type of space, for instance because of multiple
different host bus interface chipsets.
A range in bus space is described by a bus address and a bus size. The bus
address describes the start of the range in bus space. The bus size describes
the size of the range in bytes. Busses which are not byte addressable may
require use of bus space ranges with appropriately aligned addresses and
properly rounded sizes.
Access to regions of bus space is facilitated by use of bus space handles, which
are usually created by mapping a specific range of a bus space. Handles may
also be created by allocating and mapping a range of bus space, the actual
location of which is picked by the implementation within bounds specified by
the caller of the allocation function.
All of the bus space access functions require one bus space tag argument, at
least one handle argument, and at least one offset argument (a bus size). The
bus space tag specifies the space, each handle specifies a region in the
space, and each offset specifies the offset into the region of the actual
location(s) to be accessed. Offsets are given in bytes, though busses may
impose alignment constraints. The offset used to access data relative to a
given handle must be such that all of the data being accessed is in the mapped
region that the handle describes. Trying to access data outside that region is
an error.
Because some architectures' memory systems use buffering to improve memory and
device access performance, there is a mechanism which can be used to create
“barriers” in the bus space read and write stream. There are
three types of barriers: read, write, and read/write. All reads started to the
region before a read barrier must complete before any reads after the read
barrier are started. (The analogous requirement is true for write barriers.)
Read/write barriers force all reads and writes started before the barrier to
complete before any reads or writes after the barrier are started.
Correctly-written drivers will include all appropriate barriers, and assume
only the read/write ordering imposed by the barrier operations.
People trying to write portable drivers with the
bus_space
functions should try to make
minimal assumptions about what the system allows. In particular, they should
expect that the system requires bus space addresses being accessed to be
naturally aligned (i.e., base address of handle added to offset is a multiple
of the access size), and that the system does alignment checking on pointers
(i.e., pointer to objects being read and written must point to
properly-aligned data).
The descriptions of the
bus_space
functions
given below all assume that they are called with proper arguments. If called
with invalid arguments or arguments that are out of range (e.g. trying to
access data outside of the region mapped when a given handle was created),
undefined behaviour results. In that case, they may cause the system to halt,
either intentionally (via panic) or unintentionally (by causing a fatal trap
of by some other means) or may cause improper operation which is not
immediately fatal. Functions which return
void or which return data read from bus space
(i.e., functions which do not obviously return an error code) do not fail.
They could only fail if given invalid arguments, and in that case their
behaviour is undefined. Functions which take a count of bytes have undefined
results if the specified
count is zero.
TYPES¶
Several types are defined in
<machine/bus.h>
to facilitate use of the
bus_space
functions by drivers.
bus_addr_t¶
The
bus_addr_t type is used to describe bus
addresses. It must be an unsigned integral type capable of holding the largest
bus address usable by the architecture. This type is primarily used when
mapping and unmapping bus space.
bus_size_t¶
The
bus_size_t type is used to describe sizes
of ranges in bus space. It must be an unsigned integral type capable of
holding the size of the largest bus address range usable on the architecture.
This type is used by virtually all of the
bus_space
functions, describing sizes when
mapping regions and offsets into regions when performing space access
operations.
bus_space_tag_t¶
The
bus_space_tag_t type is used to describe a
particular bus space on a machine. Its contents are machine-dependent and
should be considered opaque by machine-independent code. This type is used by
all
bus_space
functions to name the space
on which they are operating.
bus_space_handle_t¶
The
bus_space_handle_t type is used to describe
a mapping of a range of bus space. Its contents are machine-dependent and
should be considered opaque by machine-independent code. This type is used
when performing bus space access operations.
MAPPING AND UNMAPPING BUS SPACE¶
This section is specific to the
NetBSD version of these
functions and may or may not apply to the
FreeBSD
version.
Bus space must be mapped before it can be used, and should be unmapped when it
is no longer needed. The
bus_space_map
()
and
bus_space_unmap
() functions provide
these capabilities.
Some drivers need to be able to pass a subregion of already-mapped bus space to
another driver or module within a driver. The
bus_space_subregion
() function allows such
subregions to be created.
bus_space_map(space, address, size, flags, handlep)¶
The
bus_space_map
() function maps the region
of bus space named by the
space,
address, and
size arguments. If successful, it returns
zero and fills in the bus space handle pointed to by
handlep with the handle that can be used to
access the mapped region. If unsuccessful, it will return non-zero and leave
the bus space handle pointed to by
handlep in
an undefined state.
The
flags argument controls how the space is to
be mapped. Supported flags include:
BUS_SPACE_MAP_CACHEABLE
- Try to map the space so that accesses can be cached and/or prefetched by
the system. If this flag is not specified, the implementation should map
the space so that it will not be cached or prefetched.
This flag must have a value of 1 on all implementations for backward
compatibility.
BUS_SPACE_MAP_LINEAR
- Try to map the space so that its contents can be accessed linearly via
normal memory access methods (e.g. pointer dereferencing and structure
accesses). This is useful when software wants to do direct access to a
memory device, e.g. a frame buffer. If this flag is specified and linear
mapping is not possible, the
bus_space_map
() call should fail. If
this flag is not specified, the system may map the space in whatever way
is most convenient.
Not all combinations of flags make sense or are supported with all spaces. For
instance,
BUS_SPACE_MAP_CACHEABLE
may be
meaningless when used on many systems' I/O port spaces, and on some systems
BUS_SPACE_MAP_LINEAR
without
BUS_SPACE_MAP_CACHEABLE
may never work.
When the system hardware or firmware provides hints as to how spaces should be
mapped (e.g. the PCI memory mapping registers' “prefetchable”
bit), those hints should be followed for maximum compatibility. On some
systems, requesting a mapping that cannot be satisfied (e.g. requesting a
non-cacheable mapping when the system can only provide a cacheable one) will
cause the request to fail.
Some implementations may keep track of use of bus space for some or all bus
spaces and refuse to allow duplicate allocations. This is encouraged for bus
spaces which have no notion of slot-specific space addressing, such as ISA and
VME, and for spaces which coexist with those spaces (e.g. EISA and PCI memory
and I/O spaces co-existing with ISA memory and I/O spaces).
Mapped regions may contain areas for which there is no device on the bus. If
space in those areas is accessed, the results are bus-dependent.
bus_space_unmap(space, handle, size)¶
The
bus_space_unmap
() function unmaps a
region of bus space mapped with
bus_space_map
(). When unmapping a region,
the
size specified should be the same as the
size given to
bus_space_map
() when mapping
that region.
After
bus_space_unmap
() is called on a
handle, that handle is no longer valid. (If copies were made of the handle
they are no longer valid, either.)
This function will never fail. If it would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case,
bus_space_unmap
() will never return.
bus_space_subregion(space, handle, offset, size, nhandlep)¶
The
bus_space_subregion
() function is a
convenience function which makes a new handle to some subregion of an
already-mapped region of bus space. The subregion described by the new handle
starts at byte offset
offset into the region
described by
handle, with the size give by
size, and must be wholly contained within the
original region.
If successful,
bus_space_subregion
() returns
zero and fills in the bus space handle pointed to by
nhandlep. If unsuccessful, it returns
non-zero and leaves the bus space handle pointed to by
nhandlep in an undefined state. In either
case, the handle described by
handle remains
valid and is unmodified.
When done with a handle created by
bus_space_subregion
(), the handle should be
thrown away. Under no circumstances should
bus_space_unmap
() be used on the handle.
Doing so may confuse any resource management being done on the space, and will
result in undefined behaviour. When
bus_space_unmap
() or
bus_space_free
() is called on a handle, all
subregions of that handle become invalid.
ALLOCATING AND FREEING BUS SPACE¶
This section is specific to the
NetBSD version of these
functions and may or may not apply to the
FreeBSD
version.
Some devices require or allow bus space to be allocated by the operating system
for device use. When the devices no longer need the space, the operating
system should free it for use by other devices. The
bus_space_alloc
() and
bus_space_free
() functions provide these
capabilities.
bus_space_alloc(space, reg_start, reg_end, size, alignment, boundary, flags, addrp, handlep)¶
The
bus_space_alloc
() function allocates and
maps a region of bus space with the size given by
size, corresponding to the given constraints.
If successful, it returns zero, fills in the bus address pointed to by
addrp with the bus space address of the
allocated region, and fills in the bus space handle pointed to by
handlep with the handle that can be used to
access that region. If unsuccessful, it returns non-zero and leaves the bus
address pointed to by
addrp and the bus space
handle pointed to by
handlep in an undefined
state.
Constraints on the allocation are given by the
reg_start,
reg_end,
alignment, and
boundary parameters. The allocated region
will start at or after
reg_start and end
before or at
reg_end. The
alignment constraint must be a power of two,
and the allocated region will start at an address that is an even multiple of
that power of two. The
boundary constraint,
if non-zero, ensures that the region is allocated so that
first address in region /
boundary has the same value as
last address in region /
boundary. If the constraints cannot be met,
bus_space_alloc
() will fail. It is an error
to specify a set of constraints that can never be met (for example,
size greater than
boundary).
The
flags parameter is the same as the
like-named parameter to
bus_space_map
(),
the same flag values should be used, and they have the same meanings.
Handles created by
bus_space_alloc
() should
only be freed with
bus_space_free
(). Trying
to use
bus_space_unmap
() on them causes
undefined behaviour. The
bus_space_subregion
() function can be used
on handles created by
bus_space_alloc
().
bus_space_free(space, handle, size)¶
The
bus_space_free
() function unmaps and
frees a region of bus space mapped and allocated with
bus_space_alloc
(). When unmapping a region,
the
size specified should be the same as the
size given to
bus_space_alloc
() when
allocating the region.
After
bus_space_free
() is called on a handle,
that handle is no longer valid. (If copies were made of the handle, they are
no longer valid, either.)
This function will never fail. If it would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case,
bus_space_free
() will never return.
READING AND WRITING SINGLE DATA ITEMS¶
The simplest way to access bus space is to read or write a single data item. The
bus_space_read_N
() and
bus_space_write_N
() families of functions
provide the ability to read and write 1, 2, 4, and 8 byte data items on busses
which support those access sizes.
bus_space_read_1(space, handle, offset)¶
bus_space_read_2(space, handle, offset)¶
bus_space_read_4(space, handle, offset)¶
bus_space_read_8(space, handle, offset)¶
The
bus_space_read_N
() family of functions
reads a 1, 2, 4, or 8 byte data item from the offset specified by
offset into the region specified by
handle of the bus space specified by
space. The location being read must lie
within the bus space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data item being read. On some systems, not obeying this
requirement may cause incorrect data to be read, on others it may cause a
system crash.
Read operations done by the
bus_space_read_N
() functions may be
executed out of order with respect to other pending read and write operations
unless order is enforced by use of the
bus_space_barrier
() function.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_write_1(space, handle, offset, value)¶
bus_space_write_2(space, handle, offset, value)¶
bus_space_write_4(space, handle, offset, value)¶
bus_space_write_8(space, handle, offset, value)¶
The
bus_space_write_N
() family of functions
writes a 1, 2, 4, or 8 byte data item to the offset specified by
offset into the region specified by
handle of the bus space specified by
space. The location being written must lie
within the bus space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data item being written. On some systems, not obeying this
requirement may cause incorrect data to be written, on others it may cause a
system crash.
Write operations done by the
bus_space_write_N
() functions may be
executed out of order with respect to other pending read and write operations
unless order is enforced by use of the
bus_space_barrier
() function.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
BARRIERS¶
In order to allow high-performance buffering implementations to avoid bus
activity on every operation, read and write ordering should be specified
explicitly by drivers when necessary. The
bus_space_barrier
() function provides that
ability.
bus_space_barrier(space, handle, offset, length, flags)¶
The
bus_space_barrier
() function enforces
ordering of bus space read and write operations for the specified subregion
(described by the
offset and
length parameters) of the region named by
handle in the space named by
space.
The
flags argument controls what types of
operations are to be ordered. Supported flags are:
BUS_SPACE_BARRIER_READ
- Synchronize read operations.
BUS_SPACE_BARRIER_WRITE
- Synchronize write operations.
Those flags can be combined (or-ed together) to enforce ordering on both read
and write operations.
All of the specified type(s) of operation which are done to the region before
the barrier operation are guaranteed to complete before any of the specified
type(s) of operation done after the barrier.
Example: Consider a hypothetical device with two single-byte ports, one
write-only input port (at offset 0) and a read-only output port (at offset 1).
Operation of the device is as follows: data bytes are written to the input
port, and are placed by the device on a stack, the top of which is read by
reading from the output port. The sequence to correctly write two data bytes
to the device then read those two data bytes back would be:
/*
* t and h are the tag and handle for the mapped device's
* space.
*/
bus_space_write_1(t, h, 0, data0);
bus_space_barrier(t, h, 0, 1, BUS_SPACE_BARRIER_WRITE); /* 1 */
bus_space_write_1(t, h, 0, data1);
bus_space_barrier(t, h, 0, 2,
BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE); /* 2 */
ndata1 = bus_space_read_1(t, h, 1);
bus_space_barrier(t, h, 1, 1, BUS_SPACE_BARRIER_READ); /* 3 */
ndata0 = bus_space_read_1(t, h, 1);
/* data0 == ndata0, data1 == ndata1 */
The first barrier makes sure that the first write finishes before the second
write is issued, so that two writes to the input port are done in order and
are not collapsed into a single write. This ensures that the data bytes are
written to the device correctly and in order.
The second barrier makes sure that the writes to the output port finish before
any of the reads to the input port are issued, thereby making sure that all of
the writes are finished before data is read. This ensures that the first byte
read from the device really is the last one that was written.
The third barrier makes sure that the first read finishes before the second read
is issued, ensuring that data is read correctly and in order.
The barriers in the example above are specified to cover the absolute minimum
number of bus space locations. It is correct (and often easier) to make
barrier operations cover the device's whole range of bus space, that is, to
specify an offset of zero and the size of the whole region.
REGION OPERATIONS¶
Some devices use buffers which are mapped as regions in bus space. Often,
drivers want to copy the contents of those buffers to or from memory, e.g.
into mbufs which can be passed to higher levels of the system or from mbufs to
be output to a network. In order to allow drivers to do this as efficiently as
possible, the
bus_space_read_region_N
() and
bus_space_write_region_N
() families of
functions are provided.
Drivers occasionally need to copy one region of a bus space to another, or to
set all locations in a region of bus space to contain a single value. The
bus_space_copy_region_N
() family of
functions and the
bus_space_set_region_N
()
family of functions allow drivers to perform these operations.
bus_space_read_region_1(space, handle, offset, datap, count)¶
bus_space_read_region_2(space, handle, offset, datap, count)¶
bus_space_read_region_4(space, handle, offset, datap, count)¶
bus_space_read_region_8(space, handle, offset, datap, count)¶
The
bus_space_read_region_N
() family of
functions reads
count 1, 2, 4, or 8 byte data
items from bus space starting at byte offset
offset in the region specified by
handle of the bus space specified by
space and writes them into the array
specified by
datap. Each successive data item
is read from an offset 1, 2, 4, or 8 bytes after the previous data item
(depending on which function is used). All locations being read must lie
within the bus space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being read and the data array pointer should be
properly aligned. On some systems, not obeying these requirements may cause
incorrect data to be read, on others it may cause a system crash.
Read operations done by the
bus_space_read_region_N
() functions may be
executed in any order. They may also be executed out of order with respect to
other pending read and write operations unless order is enforced by use of the
bus_space_barrier
() function. There is no
way to insert barriers between reads of individual bus space locations
executed by the
bus_space_read_region_N
()
functions.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_write_region_1(space, handle, offset, datap, count)¶
bus_space_write_region_2(space, handle, offset, datap, count)¶
bus_space_write_region_4(space, handle, offset, datap, count)¶
bus_space_write_region_8(space, handle, offset, datap, count)¶
The
bus_space_write_region_N
() family of
functions reads
count 1, 2, 4, or 8 byte data
items from the array specified by
datap and
writes them to bus space starting at byte offset
offset in the region specified by
handle of the bus space specified by
space. Each successive data item is written
to an offset 1, 2, 4, or 8 bytes after the previous data item (depending on
which function is used). All locations being written must lie within the bus
space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being written and the data array pointer should be
properly aligned. On some systems, not obeying these requirements may cause
incorrect data to be written, on others it may cause a system crash.
Write operations done by the
bus_space_write_region_N
() functions may be
executed in any order. They may also be executed out of order with respect to
other pending read and write operations unless order is enforced by use of the
bus_space_barrier
() function. There is no
way to insert barriers between writes of individual bus space locations
executed by the
bus_space_write_region_N
()
functions.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_copy_region_1(space, srchandle, srcoffset, dsthandle, dstoffset, count)¶
bus_space_copy_region_2(space, srchandle, srcoffset, dsthandle, dstoffset, count)¶
bus_space_copy_region_4(space, srchandle, srcoffset, dsthandle, dstoffset, count)¶
bus_space_copy_region_8(space, srchandle, srcoffset, dsthandle, dstoffset, count)¶
The
bus_space_copy_region_N
() family of
functions copies
count 1, 2, 4, or 8 byte
data items in bus space from the area starting at byte offset
srcoffset in the region specified by
srchandle of the bus space specified by
space to the area starting at byte offset
dstoffset in the region specified by
dsthandle in the same bus space. Each
successive data item read or written has an offset 1, 2, 4, or 8 bytes after
the previous data item (depending on which function is used). All locations
being read and written must lie within the bus space region specified by their
respective handles.
For portability, the starting addresses of the regions specified by the each
handle plus its respective offset should be a multiple of the size of data
items being copied. On some systems, not obeying this requirement may cause
incorrect data to be copied, on others it may cause a system crash.
Read and write operations done by the
bus_space_copy_region_N
() functions may be
executed in any order. They may also be executed out of order with respect to
other pending read and write operations unless order is enforced by use of the
bus_space_barrier
() function. There is no
way to insert barriers between reads or writes of individual bus space
locations executed by the
bus_space_copy_region_N
() functions.
Overlapping copies between different subregions of a single region of bus space
are handled correctly by the
bus_space_copy_region_N
() functions.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_set_region_1(space, handle, offset, value, count)¶
bus_space_set_region_2(space, handle, offset, value, count)¶
bus_space_set_region_4(space, handle, offset, value, count)¶
bus_space_set_region_8(space, handle, offset, value, count)¶
The
bus_space_set_region_N
() family of
functions writes the given
value to
count 1, 2, 4, or 8 byte data items in bus
space starting at byte offset
offset in the
region specified by
handle of the bus space
specified by
space. Each successive data item
has an offset 1, 2, 4, or 8 bytes after the previous data item (depending on
which function is used). All locations being written must lie within the bus
space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being written. On some systems, not obeying this
requirement may cause incorrect data to be written, on others it may cause a
system crash.
Write operations done by the
bus_space_set_region_N
() functions may be
executed in any order. They may also be executed out of order with respect to
other pending read and write operations unless order is enforced by use of the
bus_space_barrier
() function. There is no
way to insert barriers between writes of individual bus space locations
executed by the
bus_space_set_region_N
()
functions.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
READING AND WRITING A SINGLE LOCATION MULTIPLE TIMES¶
Some devices implement single locations in bus space which are to be read or
written multiple times to communicate data, e.g. some ethernet devices' packet
buffer FIFOs. In order to allow drivers to manipulate these types of devices
as efficiently as possible, the
bus_space_read_multi_N
(),
bus_space_set_multi_N
(), and
bus_space_write_multi_N
() families of
functions are provided.
bus_space_read_multi_1(space, handle, offset, datap, count)¶
bus_space_read_multi_2(space, handle, offset, datap, count)¶
bus_space_read_multi_4(space, handle, offset, datap, count)¶
bus_space_read_multi_8(space, handle, offset, datap, count)¶
The
bus_space_read_multi_N
() family of
functions reads
count 1, 2, 4, or 8 byte data
items from bus space at byte offset
offset in
the region specified by
handle of the bus
space specified by
space and writes them into
the array specified by
datap. Each successive
data item is read from the same location in bus space. The location being read
must lie within the bus space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being read and the data array pointer should be
properly aligned. On some systems, not obeying these requirements may cause
incorrect data to be read, on others it may cause a system crash.
Read operations done by the
bus_space_read_multi_N
() functions may be
executed out of order with respect to other pending read and write operations
unless order is enforced by use of the
bus_space_barrier
() function. Because the
bus_space_read_multi_N
() functions read the
same bus space location multiple times, they place an implicit read barrier
between each successive read of that bus space location.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_write_multi_1(space, handle, offset, datap, count)¶
bus_space_write_multi_2(space, handle, offset, datap, count)¶
bus_space_write_multi_4(space, handle, offset, datap, count)¶
bus_space_write_multi_8(space, handle, offset, datap, count)¶
The
bus_space_write_multi_N
() family of
functions reads
count 1, 2, 4, or 8 byte data
items from the array specified by
datap and
writes them into bus space at byte offset
offset in the region specified by
handle of the bus space specified by
space. Each successive data item is written
to the same location in bus space. The location being written must lie within
the bus space region specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being written and the data array pointer should be
properly aligned. On some systems, not obeying these requirements may cause
incorrect data to be written, on others it may cause a system crash.
Write operations done by the
bus_space_write_multi_N
() functions may be
executed out of order with respect to other pending read and write operations
unless order is enforced by use of the
bus_space_barrier
() function. Because the
bus_space_write_multi_N
() functions write
the same bus space location multiple times, they place an implicit write
barrier between each successive write of that bus space location.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
bus_space_set_multi_1(space, handle, offset, value, count)¶
bus_space_set_multi_2(space, handle, offset, value, count)¶
bus_space_set_multi_4(space, handle, offset, value, count)¶
bus_space_set_multi_8(space, handle, offset, value, count)¶
The
bus_space_set_multi_N
() writes
value into bus space at byte offset
offset in the region specified by
handle of the bus space specified by
space,
count
times. The location being written must lie within the bus space region
specified by
handle.
For portability, the starting address of the region specified by
handle plus the offset should be a multiple
of the size of data items being written and the data array pointer should be
properly aligned. On some systems, not obeying these requirements may cause
incorrect data to be written, on others it may cause a system crash.
Write operations done by the
bus_space_set_multi_N
() functions may be
executed out of order with respect to other pending read and write operations
unless order is enforced by use of the
bus_space_barrier
() function. Because the
bus_space_set_multi_N
() functions write the
same bus space location multiple times, they place an implicit write barrier
between each successive write of that bus space location.
These functions will never fail. If they would fail (e.g. because of an argument
error), that indicates a software bug which should cause a panic. In that
case, they will never return.
STREAM FUNCTIONS¶
Most of the
bus_space
functions imply a host
byte-order and a bus byte-order and take care of any translation for the
caller. In some cases, however, hardware may map a FIFO or some other memory
region for which the caller may want to use multi-word, yet untranslated
access. Access to these types of memory regions should be with the
bus_space_*_stream_N
() functions.
bus_space_read_stream_1
()
-
bus_space_read_stream_2
()
-
bus_space_read_stream_4
()
-
bus_space_read_stream_8
()
-
bus_space_read_multi_stream_1
()
-
bus_space_read_multi_stream_2
()
-
bus_space_read_multi_stream_4
()
-
bus_space_read_multi_stream_8
()
-
bus_space_read_region_stream_1
()
-
bus_space_read_region_stream_2
()
-
bus_space_read_region_stream_4
()
-
bus_space_read_region_stream_8
()
-
bus_space_write_stream_1
()
-
bus_space_write_stream_2
()
-
bus_space_write_stream_4
()
-
bus_space_write_stream_8
()
-
bus_space_write_multi_stream_1
()
-
bus_space_write_multi_stream_2
()
-
bus_space_write_multi_stream_4
()
-
bus_space_write_multi_stream_8
()
-
bus_space_write_region_stream_1
()
-
bus_space_write_region_stream_2
()
-
bus_space_write_region_stream_4
()
-
bus_space_write_region_stream_8
()
-
bus_space_copy_region_stream_1
()
-
bus_space_copy_region_stream_2
()
-
bus_space_copy_region_stream_4
()
-
bus_space_copy_region_stream_8
()
-
bus_space_set_multi_stream_1
()
-
bus_space_set_multi_stream_2
()
-
bus_space_set_multi_stream_4
()
-
bus_space_set_multi_stream_8
()
-
bus_space_set_region_stream_1
()
-
bus_space_set_region_stream_2
()
-
bus_space_set_region_stream_4
()
-
bus_space_set_region_stream_8
()
-
These functions are defined just as their non-stream counterparts, except that
they provide no byte-order translation.
COMPATIBILITY¶
The current
NetBSD version of the
bus_space
interface specification differs
slightly from the original specification that came into wide use and
FreeBSD adopted. A few of the function names and
arguments have changed for consistency and increased functionality.
SEE ALSO¶
bus_dma(9)
HISTORY¶
The
bus_space
functions were introduced in a
different form (memory and I/O spaces were accessed via different sets of
functions) in
NetBSD 1.2. The functions were merged to
work on generic “spaces” early in the
NetBSD
1.3 development cycle, and many drivers were converted to use them.
This document was written later during the
NetBSD 1.3
development cycle, and the specification was updated to fix some consistency
problems and to add some missing functionality.
The manual page was then adapted to the version of the interface that
FreeBSD imported for the CAM SCSI drivers, plus
subsequent evolution. The
FreeBSD
bus_space
version was imported in
FreeBSD 3.0.
AUTHORS¶
The
bus_space
interfaces were designed and
implemented by the
NetBSD developer community. Primary
contributors and implementors were
Chris
Demetriou,
Jason Thorpe, and
Charles Hannum, but the rest of the
NetBSD developers and the user community played a
significant role in development.
Justin Gibbs ported these interfaces to
FreeBSD.
Chris Demetriou wrote this manual page.
Warner Losh modified it for the
FreeBSD implementation.
BUGS¶
This manual may not completely and accurately document the interface, and many
parts of the interface are unspecified.