Data Structures for Drivers ddidmareq(9S)
NAME
ddidmareq - DMA Request structure
SYNOPSIS
#include
INTERFACE LEVEL
Solaris DI specific (Solaris DI). This interface is
obsolete.
DESCRIPTION
A ddidmareq structure describes a request for DMA
resources. A driver can use it to describe forms of alloca-
tions and ways to allocate DMA resources for a DMA request.
STRUCTURE MEMBERS
ddidmalimt *dmarlimits; /* Caller's dma engine
constraints */
uintt dmarflags; /* Contains info for
mapping routines */
int (*dmarfp)(caddrt);/* Callback function */
caddrt dmararg; /* Callback function's argument */
ddidmaobjt dmarobject; /* Descrip. of object
to be mapped */
For the definition of the DMA limits structure, which
dmarlimits points to, see ddidmalimsparc(9S) or
ddidmalimx86(9S).
Valid values for dmarflags are:
DIDMAWRITE /* Direction memory --> IO */
DIDMAREAD /* Direction IO --> memory */
DIDMARDWR /* Both read and write */
DIDMAREDZONE /* Establish MU redzone at end of mapping */
DIDMAPARTIAL /* Partial mapping is allowed */
DIDMACONSISTENT /* Byte consistent access wanted */
DIDMASBUS64BIT /* Use 64 bit capability on SBus */
DIDMAWRITE, DIDMAREAD, and DIDMARDWR describe the
intended direction of the DMA transfer. Some implementations
might explicitly disallow DIDMARDWR.
DIDMAREDZONE asks the system to establish a protected
red zone after the object. The DMA resource allocation
SunOS 5.11 Last change: 12 Oct 2005 1
Data Structures for Drivers ddidmareq(9S)
functions do not guarantee the success of this request, as
some implementations might not have the hardware ability to
support it.
DIDMAPARTIAL lets the system know that the caller can
accept partial mapping. That is, if the size of the object
exceeds the resources available, the system allocates only a
portion of the object and returns status indicating this
partial allocation. At a later point, the caller can use
ddidmacurwin(9F) and ddidmamovwin(9F) to change the
valid portion of the object that has resources allocated.
DIDMACONSISTENT gives a hint to the system that the
object should be mapped for byte consistent access. Normal
data transfers usually use a streaming mode of operation.
They start at a specific point, transfer a fairly large
amount of data sequentially, and then stop, usually on an
aligned boundary. Control mode data transfers for memory-
resident device control blocks (for example, Ethernet mes-
sage descriptors) do not access memory in such a sequential
fashion. Instead, they tend to modify a few words or bytes,
move around and maybe modify a few more.
Many machine implementations make this non-sequential memory
access difficult to control in a generic and seamless
fashion. Therefore, explicit synchronization steps using
ddidmasync(9F) or ddidmafree(9F) are required to make
the view of a memory object shared between a CPU and a DMA
device consistent. However, proper use of the
DIDMACONSISTENT flag can create a condition in which a
system will pick resources in a way that makes these syn-
chronization steps are as efficient as possible.
DIDMASBUS64BIT tells the system that the device can per-
form 64-bit transfers on a 64-bit SBus. If the SBus does not
support 64-bit data transfers, data will be transferred in
32-bit mode.
The callback function specified by the member dmarfp indi-
cates how a caller to one of the DMA resource allocation
functions wants to deal with the possibility of resources
not being available. (See ddidmasetup(9F).) If dmarfp is
set to DIDMADONTWAIT, then the caller does not care if
the allocation fails, and can deal with an allocation
failure appropriately. Setting dmarfp to DIDMASLEP
indicates the caller wants to have the allocation routines
wait for resources to become available. If any other value
SunOS 5.11 Last change: 12 Oct 2005 2
Data Structures for Drivers ddidmareq(9S)
is set, and a DMA resource allocation fails, this value is
assumed to be a function to call later, when resources
become available. When the specified function is called, it
is passed the value set in the structure member dmararg.
The specified callback function must return either:
0 Indicating that it attempted to allocate a DMA resource
but failed to do so, again, in which case the callback
function will be put back on a list to be called again
later.
1 Indicating either success at allocating DMA resources
or that it no longer wants to retry.
The callback function is called in interrupt context. There-
fore, only system functions and contexts that are accessible
from interrupt context are available. The callback function
must take whatever steps necessary to protect its critical
resources, data structures, and queues.
It is possible that a call to ddidmafree(9F), which frees
DMA resources, might cause a callback function to be called
and, unless some care is taken, an undesired recursion can
occur. This can cause an undesired recursive
mutexenter(9F), which makes the system panic.
dmarobject Structure
The dmarobject member of the ddidmareq structure is
itself a complex and extensible structure:
uintt dmaosize; /* size, in bytes, of the object */
ddidmaatypt dmaotype; /* type of object */
ddidmaaobjt dmaoobj; /* the object described */
The dmaosize element is the size, in bytes, of the object
resources allocated for DMA.
The dmaotype element selects the kind of object described
by dmaoobj. It can be set to DMAOTYPVADR, indicating
virtual addresses.
The last element, dmaoobj, consists of the virtual address
type:
SunOS 5.11 Last change: 12 Oct 2005 3
Data Structures for Drivers ddidmareq(9S)
struct vaddress virtobj;
It is specified as:
struct vaddress {
caddrt vaddr; /* base virtual address */
struct as *vas; /* pointer to address space */
void *vpriv; /* priv data for shadow I/O */
};
ATRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
ATRIBUTE TYPE ATRIBUTE VALUE
Interface Stability Obsolete
SEE ALSO
ddidmaaddrsetup(9F), ddidmabufsetup(9F),
ddidmacurwin(9F), ddidmafree(9F), ddidmamovwin(9F),
ddidmasetup(9F), ddidmasync(9F), mutex(9F)
Writing Device Drivers
SunOS 5.11 Last change: 12 Oct 2005 4
|
