1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
'\" te
.\" Copyright (c) 2005, 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]
.TH DDI_DMA_REQ 9S "Oct 12, 2005"
.SH NAME
ddi_dma_req \- DMA Request structure
.SH SYNOPSIS
.LP
.nf
#include <sys/ddidmareq.h>
.fi
.SH INTERFACE LEVEL
.sp
.LP
Solaris DDI specific (Solaris DDI). This interface is obsolete.
.SH DESCRIPTION
.sp
.LP
A \fBddi_dma_req\fR structure describes a request for \fBDMA\fR resources. A
driver can use it to describe forms of allocations and ways to allocate
\fBDMA\fR resources for a \fBDMA\fR request.
.SH STRUCTURE MEMBERS
.sp
.in +2
.nf
ddi_dma_lim_t *dmar_limits; /* Caller's dma engine
constraints */
uint_t dmar_flags; /* Contains info for
mapping routines */
int (*dmar_fp)(caddr_t);/* Callback function */
caddr_t dmar_arg; /* Callback function's argument */
ddi_dma_obj_t dmar_object; /* Descrip. of object
to be mapped */
.fi
.in -2
.sp
.LP
For the definition of the \fBDMA\fR limits structure, which \fBdmar_limits\fR
points to, see \fBddi_dma_lim_sparc\fR(9S) or \fBddi_dma_lim_x86\fR(9S).
.sp
.LP
Valid values for \fBdmar_flags\fR are:
.sp
.in +2
.nf
DDI_DMA_WRITE /* Direction memory --> IO */
DDI_DMA_READ /* Direction IO --> memory */
DDI_DMA_RDWR /* Both read and write */
DDI_DMA_REDZONE /* Establish MMU redzone at end of mapping */
DDI_DMA_PARTIAL /* Partial mapping is allowed */
DDI_DMA_CONSISTENT /* Byte consistent access wanted */
DDI_DMA_SBUS_64BIT /* Use 64 bit capability on SBus */
.fi
.in -2
.sp
.LP
\fBDDI_DMA_WRITE\fR, \fBDDI_DMA_READ\fR, and \fBDDI_DMA_RDWR\fR describe the
intended direction of the \fBDMA \fRtransfer. Some implementations might
explicitly disallow \fBDDI_DMA_RDWR\fR.
.sp
.LP
\fBDDI_DMA_REDZONE\fR asks the system to establish a protected \fBred zone\fR
after the object. The \fBDMA\fR resource allocation functions do not guarantee
the success of this request, as some implementations might not have the
hardware ability to support it.
.sp
.LP
\fBDDI_DMA_PARTIAL\fR 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
\fBddi_dma_curwin\fR(9F) and \fBddi_dma_movwin\fR(9F) to change the valid
portion of the object that has resources allocated.
.sp
.LP
\fBDDI_DMA_CONSISTENT\fR gives a hint to the system that the object should be
mapped for \fBbyte consistent\fR access. Normal data transfers usually use a
\fBstreaming\fR 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 message 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.
.sp
.LP
Many machine implementations make this non-sequential memory access difficult
to control in a generic and seamless fashion. Therefore, explicit
synchronization steps using \fBddi_dma_sync\fR(9F) or \fBddi_dma_free\fR(9F)
are required to make the view of a memory object shared between a \fBCPU \fRand
a \fBDMA\fR device consistent. However, proper use of the
\fBDDI_DMA_CONSISTENT\fR flag can create a condition in which a system will
pick resources in a way that makes these synchronization steps are as efficient
as possible.
.sp
.LP
\fBDDI_DMA_SBUS_64BIT\fR tells the system that the device can perform 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.
.sp
.LP
The callback function specified by the member \fBdmar_fp\fR indicates how a
caller to one of the \fBDMA\fR resource allocation functions wants to deal with
the possibility of resources not being available. (See
\fBddi_dma_setup\fR(9F).) If \fBdmar_fp\fR is set to \fBDDI_DMA_DONTWAIT\fR,
then the caller does not care if the allocation fails, and can deal with an
allocation failure appropriately. Setting \fBdmar_fp\fR to \fBDDI_DMA_SLEEP\fR
indicates the caller wants to have the allocation routines wait for resources
to become available. If any other value is set, and a \fBDMA\fR 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 \fBdmar_arg\fR. The specified callback
function \fBmust\fR return either:
.sp
.ne 2
.na
\fB\fB0\fR\fR
.ad
.RS 5n
Indicating that it attempted to allocate a \fBDMA\fR 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.
.RE
.sp
.ne 2
.na
\fB\fB1\fR\fR
.ad
.RS 5n
Indicating either success at allocating \fBDMA\fR resources or that it no
longer wants to retry.
.RE
.sp
.LP
The callback function is called in interrupt context. Therefore, 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.
.sp
.LP
It is possible that a call to \fBddi_dma_free\fR(9F), which frees \fBDMA\fR
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 \fBmutex_enter\fR(9F), which makes the system panic.
.SS "dmar_object Structure"
.sp
.LP
The \fBdmar_object\fR member of the \fBddi_dma_req\fR structure is itself a
complex and extensible structure:
.sp
.in +2
.nf
uint_t dmao_size; /* size, in bytes, of the object */
ddi_dma_atyp_t dmao_type; /* type of object */
ddi_dma_aobj_t dmao_obj; /* the object described */
.fi
.in -2
.sp
.LP
The \fBdmao_size\fR element is the size, in bytes, of the object resources
allocated for \fBDMA\fR.
.sp
.LP
The \fBdmao_type\fR element selects the kind of object described by
\fBdmao_obj\fR. It can be set to \fBDMA_OTYP_VADDR\fR, indicating virtual
addresses.
.sp
.LP
The last element, \fBdmao_obj\fR, consists of the virtual address type:
.sp
.in +2
.nf
struct v_address virt_obj;
.fi
.in -2
.sp
.LP
It is specified as:
.sp
.in +2
.nf
struct v_address {
caddr_t v_addr; /* base virtual address */
struct as *v_as; /* pointer to address space */
void *v_priv; /* priv data for shadow I/O */
};
.fi
.in -2
.SH ATTRIBUTES
.sp
.LP
See \fBattributes\fR(5) for descriptions of the following attributes:
.sp
.sp
.TS
box;
c | c
l | l .
ATTRIBUTE TYPE ATTRIBUTE VALUE
_
Interface Stability Obsolete
.TE
.SH SEE ALSO
.sp
.LP
\fBddi_dma_addr_setup\fR(9F), \fBddi_dma_buf_setup\fR(9F),
\fBddi_dma_curwin\fR(9F), \fBddi_dma_free\fR(9F), \fBddi_dma_movwin\fR(9F),
\fBddi_dma_setup\fR(9F), \fBddi_dma_sync\fR(9F), \fBmutex\fR(9F)
.sp
.LP
\fIWriting Device Drivers\fR
|
