1ddi_dma_addr_bind_handle(9KFe)rnel Functions for Drivedrdsi_dma_addr_bind_handle(9F)
2
6 ddi_dma_addr_bind_handle - binds an address to a DMA handle
7
9 #include <sys/ddi.h>
10 #include <sys/sunddi.h>
11 int ddi_dma_addr_bind_handle(ddi_dma_handle_t handle, struct as *as,
15 caddr_t addr, size_t len, uint_t flags, int (*callback) (caddr_t) ,
16 caddr_t 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 as A pointer to an address space structure. This parameter
28 should be set to NULL, which implies kernel address
29 space.
30 addr Virtual address of the memory object.
33 len Length of the memory object in bytes.
36 flags Valid flags include:
39 DDI_DMA_WRITE Transfer direction is from memory
41 to I/O.
42 DDI_DMA_READ Transfer direction is from I/O to
45 memory.
46 DDI_DMA_RDWR Both read and write.
49 DDI_DMA_REDZONE Establish an MMU redzone at end of
52 the object.
53 DDI_DMA_PARTIAL Partial resource allocation.
56 DDI_DMA_CONSISTENT Nonsequential, random, and small
59 block transfers.
60 DDI_DMA_STREAMING Sequential, unidirectional, block-
63 sized, and block-aligned transfers.
64 callback The address of a function to call back later if resources
68 are not currently available. The following special func‐
69 tion addresses may also be used.
70 DDI_DMA_SLEEP Wait until resources are available.
72 DDI_DMA_DONTWAIT Do not wait until resources are
75 available and do not schedule a call‐
76 back.
77 arg Argument to be passed to the callback function, callback,
81 if such a function is specified.
82 cookiep A pointer to the first ddi_dma_cookie(9S) structure.
85 ccountp Upon a successful return, ccountp points to a value rep‐
88 resenting the number of cookies for this DMA object.
89
92 ddi_dma_addr_bind_handle() allocates DMA resources for a memory object
93 such that a device can perform DMA to or from the object. DMA resources
94 are allocated considering the device's DMA attributes as expressed by
95 ddi_dma_attr(9S) (see ddi_dma_alloc_handle(9F)).
96 ddi_dma_addr_bind_handle() fills in the first DMA cookie pointed to by
99 cookiep with the appropriate address, length, and bus type. *ccountp is
100 set to the number of DMA cookies representing this DMA object. Subse‐
101 quent DMA cookies must be retrieved by calling ddi_dma_nextcookie(9F)
102 the number of times specified by *countp-1.
103 When a DMA transfer completes, the driver frees up system DMA resources
106 by calling ddi_dma_unbind_handle(9F).
107 The flags argument contains information for mapping routines.
110 DDI_DMA_WRITE, DDI_DMA_READ, DDI_DMA_RDWR
112 These flags describe the intended direction of the DMA transfer.
114 DDI_DMA_STREAMING
117 This flag should be set if the device is doing sequential, unidi‐
119 rectional, block-sized, and block-aligned transfers to or from mem‐
120 ory. The alignment and padding constraints specified by the
121 minxfer and burstsizes fields in the DMA attribute structure,
122 ddi_dma_attr(9S) (see ddi_dma_alloc_handle(9F)) is used to allocate
123 the most effective hardware support for large transfers.
124 DDI_DMA_CONSISTENT
127 This flag should be set if the device accesses memory randomly, or
129 if synchronization steps using ddi_dma_sync(9F) need to be as effi‐
130 cient as possible. I/O parameter blocks used for communication
131 between a device and a driver should be allocated using
132 DDI_DMA_CONSISTENT.
133 DDI_DMA_REDZONE
136 If this flag is set, the system attempts to establish a protected
138 red zone after the object. The DMA resource allocation functions do
139 not guarantee the success of this request as some implementations
140 may not have the hardware ability to support a red zone.
141 DDI_DMA_PARTIAL
144 Setting this flag indicates the caller can accept resources for
146 part of the object. That is, if the size of the object exceeds the
147 resources available, only resources for a portion of the object are
148 allocated. The system indicates this condition by returning status
149 DDI_DMA_PARTIAL_MAP. At a later point, the caller can use
150 ddi_dma_getwin(9F) to change the valid portion of the object for
151 which resources are allocated. If resources were allocated for only
152 part of the object, ddi_dma_addr_bind_handle() returns resources
153 for the first DMAwindow. Even when DDI_DMA_PARTIAL is set, the sys‐
154 tem may decide to allocate resources for the entire object (less
155 overhead) in which case DDI_DMA_MAPPED is returned.
156 The callback function callback indicates how a caller wants to handle
160 the possibility of resources not being available. If callback is set to
161 DDI_DMA_DONTWAIT, the caller does not care if the allocation fails, and
162 can handle an allocation failure appropriately. If callback is set to
163 DDI_DMA_SLEEP, the caller wishes to have the allocation routines wait
164 for resources to become available. If any other value is set and a DMA
165 resource allocation fails, this value is assumed to be the address of a
166 function to be called when resources become available. When the speci‐
167 fied function is called, arg is passed to it as an argument. The spec‐
168 ified callback function must return either DDI_DMA_CALLBACK_RUNOUT or
169 DDI_DMA_CALLBACK_DONE. DDI_DMA_CALLBACK_RUNOUT indicates that the call‐
170 back function attempted to allocate DMA resources but failed. In this
171 case, the callback function is put back on a list to be called again
172 later. DDI_DMA_CALLBACK_DONE indicates that either the allocation of
173 DMA resources was successful or the driver no longer wishes to retry.
174 The callback function is called in interrupt context. Therefore, only
177 system functions accessible from interrupt context are be available.
178 The callback function must take whatever steps are necessary to protect
179 its critical resources, data structures, queues, and so on.
180
182 ddi_dma_addr_bind_handle() returns:
183 DDI_DMA_MAPPED Successfully allocated resources for the entire
185 object.
186 DDI_DMA_PARTIAL_MAP Successfully allocated resources for a part of
189 the object. This is acceptable when partial
190 transfers are permitted by setting the
191 DDI_DMA_PARTIAL flag in flags.
192 DDI_DMA_INUSE Another I/O transaction is using the DMA han‐
195 dle.
196 DDI_DMA_NORESOURCES No resources are available at the present time.
199 DDI_DMA_NOMAPPING The object cannot be reached by the device
202 requesting the resources.
203 DDI_DMA_TOOBIG The object is too big. A request of this size
206 can never be satisfied on this particular sys‐
207 tem. The maximum size varies depending on
208 machine and configuration.
209
212 ddi_dma_addr_bind_handle() can be called from user, kernel, or inter‐
213 rupt context, except when callback is set to DDI_DMA_SLEEP, in which
214 case it can only be called from user or kernel context.
215
217 ddi_dma_alloc_handle(9F), ddi_dma_free_handle(9F), ddi_dma_getwin(9F),
218 ddi_dma_mem_alloc(9F), ddi_dma_mem_free(9F), ddi_dma_nextcookie(9F),
219 ddi_dma_sync(9F), ddi_dma_unbind_handle(9F), ddi_umem_iosetup(9F),
220 ddi_dma_attr(9S), ddi_dma_cookie(9S)
221 Writing Device Drivers
224
226 If the driver permits partial mapping with the DDI_DMA_PARTIAL flag,
227 the number of cookies in each window may exceed the size of the
228 device's scatter/gather list as specified in the dma_attr_sgllen field
229 in the ddi_dma_attr(9S) structure. In this case, each set of cookies
230 comprising a DMA window will satisfy the DMA attributes as described
231 in the ddi_dma_attr(9S) structure in all aspects. The driver should
232 set up its DMA engine and perform one transfer for each set of cookies
233 sufficient for its scatter/gather list, up to the number of cookies for
234 this window, before advancing to the next window using
235 ddi_dma_getwin(9F).
236SunOS 5.11 26 Jul 1996 ddi_dma_addr_bind_handle(9F)