1ddi_dma_buf_bind_handle(9FK)ernel Functions for Driverdsdi_dma_buf_bind_handle(9F)
2
6 ddi_dma_buf_bind_handle - binds a system buffer to a DMA handle
7
9 #include <sys/ddi.h>
10 #include <sys/sunddi.h>
11 int ddi_dma_buf_bind_handle(ddi_dma_handle_t handle, struct buf *bp,
15 uint_t flags, int (*callback)(caddr_t), caddr_t
16 arg, ddi_dma_cookie_t *cookiep, uint_t *ccountp);
17
20 Solaris DDI specific (Solaris DDI).
21
23 handle The DMA handle previously allocated by a call to
24 ddi_dma_alloc_handle(9F).
25 bp A pointer to a system buffer structure (see buf(9S)).
28 flags Valid flags include:
31 DDI_DMA_WRITE Transfer direction is from memory to
33 I/O
34 DDI_DMA_READ Transfer direction is from I/O to
37 memory
38 DDI_DMA_RDWR Both read and write
41 DDI_DMA_REDZONE Establish an MMU redzone at end of
44 the object.
45 DDI_DMA_PARTIAL Partial resource allocation
48 DDI_DMA_CONSISTENT Nonsequential, random, and small
51 block transfers.
52 DDI_DMA_STREAMING Sequential, unidirectional, block-
55 sized, and block-aligned transfers.
56 callback The address of a function to call back later if resources
60 are not available now. The following special function
61 addresses may also be used.
62 DDI_DMA_SLEEP Wait until resources are available.
64 DDI_DMA_DONTWAIT Do not wait until resources are avail‐
67 able and do not schedule a callback.
68 arg Argument to be passed to the callback function, callback,
72 if such a function is specified.
73 cookiep A pointer to the first ddi_dma_cookie(9S) structure.
76 ccountp Upon a successful return, ccountp points to a value repre‐
79 senting the number of cookies for this DMA object.
80
83 ddi_dma_buf_bind_handle() allocates DMA resources for a system buffer
84 such that a device can perform DMA to or from the buffer. DMA resources
85 are allocated considering the device's DMA attributes as expressed by
86 ddi_dma_attr(9S) (see ddi_dma_alloc_handle(9F)).
87 ddi_dma_buf_bind_handle() fills in the first DMA cookie pointed to by
90 cookiep with the appropriate address, length, and bus type. *ccountp is
91 set to the number of DMA cookies representing this DMA object. Subse‐
92 quent DMA cookies must be retrieved by calling ddi_dma_nextcookie(9F)
93 *countp-1 times.
94 When a DMA transfer completes, the driver should free up system DMA
97 resources by calling ddi_dma_unbind_handle(9F).
98 The flags argument contains information for mapping routines.
101 DDI_DMA_WRITE, DDI_DMA_READ, DDI_DMA_RDWR
103 These flags describe the intended direction of the DMA transfer.
105 DDI_DMA_STREAMING
108 This flag should be set if the device is doing sequential, unidi‐
110 rectional, block-sized, and block-aligned transfers to or from mem‐
111 ory. The alignment and padding constraints specified by the minxfer
112 and burstsizes fields in the DMA attribute structure,
113 ddi_dma_attr(9S) (see ddi_dma_alloc_handle(9F)) is used to allocate
114 the most effective hardware support for large transfers.
115 DDI_DMA_CONSISTENT
118 This flag should be set if the device accesses memory randomly, or
120 if synchronization steps using ddi_dma_sync(9F) need to be as effi‐
121 cient as possible. I/O parameter blocks used for communication
122 between a device and a driver should be allocated using
123 DDI_DMA_CONSISTENT.
124 DDI_DMA_REDZONE
127 If this flag is set, the system attempts to establish a protected
129 red zone after the object. The DMA resource allocation functions do
130 not guarantee the success of this request as some implementations
131 may not have the hardware ability to support a red zone.
132 DDI_DMA_PARTIAL
135 Setting this flag indicates the caller can accept resources for
137 part of the object. That is, if the size of the object exceeds the
138 resources available, only resources for a portion of the object are
139 allocated. The system indicates this condition returning status
140 DDI_DMA_PARTIAL_MAP. At a later point, the caller can use
141 ddi_dma_getwin(9F) to change the valid portion of the object for
142 which resources are allocated. If resources were allocated for only
143 part of the object, ddi_dma_addr_bind_handle() returns resources
144 for the first DMA window. Even when DDI_DMA_PARTIAL is set, the
145 system may decide to allocate resources for the entire object (less
146 overhead) in which case DDI_DMA_MAPPED is returned.
147 The callback function, callback, indicates how a caller wants to handle
151 the possibility of resources not being available. If callback is set to
152 DDI_DMA_DONTWAIT, the caller does not care if the allocation fails, and
153 can handle an allocation failure appropriately. If callback is set to
154 DDI_DMA_SLEEP, the caller wishes to have the allocation routines wait
155 for resources to become available. If any other value is set, and a DMA
156 resource allocation fails, this value is assumed to be the address of a
157 function to call at a later time when resources may become available.
158 When the specified function is called, it is passed arg as an argument.
159 The specified callback function must return either DDI_DMA_CALL‐
160 BACK_RUNOUT or DDI_DMA_CALLBACK_DONE. DDI_DMA_CALLBACK_RUNOUT indicates
161 that the callback function attempted to allocate DMA resources but
162 failed to do so. In this case the callback function is put back on a
163 list to be called again later. DDI_DMA_CALLBACK_DONE indicates either a
164 successful allocation of DMA resources or that the driver no longer
165 wishes to retry.
166 The callback function is called in interrupt context. Therefore, only
169 system functions accessible from interrupt context are be available.
170 The callback function must take whatever steps necessary to protect its
171 critical resources, data structures, queues, etc.
172
174 ddi_dma_buf_bind_handle() returns:
175 DDI_DMA_MAPPED Successfully allocated resources for the entire
177 object.
178 DDI_DMA_PARTIAL_MAP Successfully allocated resources for a part of
181 the object. This is acceptable when partial
182 transfers are permitted by setting the
183 DDI_DMA_PARTIAL flag in flags.
184 DDI_DMA_INUSE Another I/O transaction is using the DMA handle.
187 DDI_DMA_NORESOURCES No resources are available at the present time.
190 DDI_DMA_NOMAPPING The object cannot be reached by the device
193 requesting the resources.
194 DDI_DMA_TOOBIG The object is too big. A request of this size
197 can never be satisfied on this particular sys‐
198 tem. The maximum size varies depending on
199 machine and configuration.
200
203 ddi_dma_buf_bind_handle() can be called from user, kernel, or interrupt
204 context, except when callback is set to DDI_DMA_SLEEP, in which case it
205 can be called from user or kernel context only.
206
208 ddi_dma_addr_bind_handle(9F), ddi_dma_alloc_handle(9F),
209 ddi_dma_free_handle(9F), ddi_dma_getwin(9F), ddi_dma_nextcookie(9F),
210 ddi_dma_sync(9F), ddi_dma_unbind_handle(9F), buf(9S), ddi_dma_attr(9S),
211 ddi_dma_cookie(9S)
212 Writing Device Drivers
215
217 If the driver permits partial mapping with the DDI_DMA_PARTIAL flag,
218 the number of cookies in each window may exceed the size of the
219 device's scatter/gather list as specified in the dma_attr_sgllen field
220 in the ddi_dma_attr(9S) structure. In this case, each set of cookies
221 comprising a DMA window will satisfy the DMA attributes as described in
222 the ddi_dma_attr(9S) structure in all aspects. The driver should set up
223 its DMA engine and perform one transfer for each set of cookies suffi‐
224 cient for its scatter/gather list, up to the number of cookies for this
225 window, before advancing to the next window using ddi_dma_getwin(9F).
226SunOS 5.11 27 Jul 1996 ddi_dma_buf_bind_handle(9F)