]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man9/bus_dma.9
Merge OpenSSL 1.1.1g.
[FreeBSD/FreeBSD.git] / share / man / man9 / bus_dma.9
1 .\" Copyright (c) 2002, 2003 Hiten M. Pandya.
2 .\" All rights reserved.
3 .\"
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
6 .\" are met:
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\"    notice, this list of conditions, and the following disclaimer,
9 .\"    without modification, immediately at the beginning of the file.
10 .\" 2. The name of the author may not be used to endorse or promote products
11 .\"    derived from this software without specific prior written permission.
12 .\"
13 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
14 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
15 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
16 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR, CONTRIBUTORS OR THE
17 .\" VOICES IN HITEN PANDYA'S HEAD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
18 .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
19 .\" TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
20 .\" PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
21 .\" LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
22 .\" NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
23 .\" SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
24 .\"
25 .\" Copyright (c) 1996, 1997, 1998, 2001 The NetBSD Foundation, Inc.
26 .\" All rights reserved.
27 .\"
28 .\" This code is derived from software contributed to The NetBSD Foundation
29 .\" by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
30 .\" NASA Ames Research Center.
31 .\"
32 .\" Redistribution and use in source and binary forms, with or without
33 .\" modification, are permitted provided that the following conditions
34 .\" are met:
35 .\" 1. Redistributions of source code must retain the above copyright
36 .\"    notice, this list of conditions and the following disclaimer.
37 .\" 2. Redistributions in binary form must reproduce the above copyright
38 .\"    notice, this list of conditions and the following disclaimer in the
39 .\"    documentation and/or other materials provided with the distribution.
40 .\"
41 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
42 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
43 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
44 .\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
45 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
46 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
47 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
48 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
49 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
50 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
51 .\" POSSIBILITY OF SUCH DAMAGE.
52 .\"
53 .\" $FreeBSD$
54 .\" $NetBSD: bus_dma.9,v 1.25 2002/10/14 13:43:16 wiz Exp $
55 .\"
56 .Dd April 14, 2020
57 .Dt BUS_DMA 9
58 .Os
59 .Sh NAME
60 .Nm bus_dma ,
61 .Nm bus_dma_tag_create ,
62 .Nm bus_dma_tag_destroy ,
63 .Nm bus_dma_template_init ,
64 .Nm bus_dma_template_tag ,
65 .Nm bus_dma_template_clone ,
66 .Nm bus_dmamap_create ,
67 .Nm bus_dmamap_destroy ,
68 .Nm bus_dmamap_load ,
69 .Nm bus_dmamap_load_bio ,
70 .Nm bus_dmamap_load_ccb ,
71 .Nm bus_dmamap_load_crp ,
72 .Nm bus_dmamap_load_mbuf ,
73 .Nm bus_dmamap_load_mbuf_sg ,
74 .Nm bus_dmamap_load_uio ,
75 .Nm bus_dmamap_unload ,
76 .Nm bus_dmamap_sync ,
77 .Nm bus_dmamem_alloc ,
78 .Nm bus_dmamem_free
79 .Nd Bus and Machine Independent DMA Mapping Interface
80 .Sh SYNOPSIS
81 .In machine/bus.h
82 .Ft int
83 .Fn bus_dma_tag_create "bus_dma_tag_t parent" "bus_size_t alignment" \
84 "bus_addr_t boundary" "bus_addr_t lowaddr" "bus_addr_t highaddr" \
85 "bus_dma_filter_t *filtfunc" "void *filtfuncarg" "bus_size_t maxsize" \
86 "int nsegments" "bus_size_t maxsegsz" "int flags" "bus_dma_lock_t *lockfunc" \
87 "void *lockfuncarg" "bus_dma_tag_t *dmat"
88 .Ft int
89 .Fn bus_dma_tag_destroy "bus_dma_tag_t dmat"
90 .Ft void
91 .Fo bus_dma_template_init
92 .Fa "bus_dma_template_t template"
93 .Fa "bus_dma_tag_t parent"
94 .Fc
95 .Ft int
96 .Fo bus_dma_template_tag
97 .Fa "bus_dma_template_t template"
98 .Fa "bus_dma_tag_t *dmat"
99 .Fc
100 .Ft void
101 .Fo bus_dma_template_clone
102 .Fa "bus_dma_template_t template"
103 .Fa "bus_dma_tag_t dmat"
104 .Fc
105 .Ft int
106 .Fn bus_dmamap_create "bus_dma_tag_t dmat" "int flags" "bus_dmamap_t *mapp"
107 .Ft int
108 .Fn bus_dmamap_destroy "bus_dma_tag_t dmat" "bus_dmamap_t map"
109 .Ft int
110 .Fn bus_dmamap_load "bus_dma_tag_t dmat" "bus_dmamap_t map" "void *buf" \
111 "bus_size_t buflen" "bus_dmamap_callback_t *callback" "void *callback_arg" \
112 "int flags"
113 .Ft int
114 .Fn bus_dmamap_load_bio "bus_dma_tag_t dmat" "bus_dmamap_t map" \
115 "struct bio *bio" "bus_dmamap_callback_t *callback" "void *callback_arg" \
116 "int flags"
117 .Ft int
118 .Fn bus_dmamap_load_ccb "bus_dma_tag_t dmat" "bus_dmamap_t map" \
119 "union ccb *ccb" "bus_dmamap_callback_t *callback" "void *callback_arg" \
120 "int flags"
121 .Ft int
122 .Fn bus_dmamap_load_crp "bus_dma_tag_t dmat" "bus_dmamap_t map" \
123 "struct crypto *crp" "bus_dmamap_callback_t *callback" "void *callback_arg" \
124 "int flags"
125 .Ft int
126 .Fn bus_dmamap_load_mbuf "bus_dma_tag_t dmat" "bus_dmamap_t map" \
127 "struct mbuf *mbuf" "bus_dmamap_callback2_t *callback" "void *callback_arg" \
128 "int flags"
129 .Ft int
130 .Fn bus_dmamap_load_mbuf_sg "bus_dma_tag_t dmat" "bus_dmamap_t map" \
131 "struct mbuf *mbuf" "bus_dma_segment_t *segs" "int *nsegs" "int flags"
132 .Ft int
133 .Fn bus_dmamap_load_uio "bus_dma_tag_t dmat" "bus_dmamap_t map" \
134 "struct uio *uio" "bus_dmamap_callback2_t *callback" "void *callback_arg" \
135 "int flags"
136 .Ft void
137 .Fn bus_dmamap_unload "bus_dma_tag_t dmat" "bus_dmamap_t map"
138 .Ft void
139 .Fn bus_dmamap_sync "bus_dma_tag_t dmat" "bus_dmamap_t map" \
140 "op"
141 .Ft int
142 .Fn bus_dmamem_alloc "bus_dma_tag_t dmat" "void **vaddr" \
143 "int flags" "bus_dmamap_t *mapp"
144 .Ft void
145 .Fn bus_dmamem_free "bus_dma_tag_t dmat" "void *vaddr" \
146 "bus_dmamap_t map"
147 .Sh DESCRIPTION
148 Direct Memory Access (DMA) is a method of transferring data
149 without involving the CPU, thus providing higher performance.
150 A DMA transaction can be achieved between device to memory,
151 device to device, or memory to memory.
152 .Pp
153 The
154 .Nm
155 API is a bus, device, and machine-independent (MI) interface to
156 DMA mechanisms.
157 It provides the client with flexibility and simplicity by
158 abstracting machine dependent issues like setting up
159 DMA mappings, handling cache issues, bus specific features
160 and limitations.
161 .Sh OVERVIEW
162 A tag structure
163 .Vt ( bus_dma_tag_t )
164 is used to describe the properties of a group of related DMA
165 transactions.
166 One way to view this is that a tag describes the limitations of a DMA engine.
167 For example, if a DMA engine in a device is limited to 32-bit addresses,
168 that limitation is specified by a parameter when creating the tag
169 for that device.
170 Similarly, a tag can be marked as requiring buffers whose addresses are
171 aligned to a specific boundary.
172 .Pp
173 Some devices may require multiple tags to describe DMA
174 transactions with differing properties.
175 For example, a device might require 16-byte alignment of its descriptor ring
176 while permitting arbitrary alignment of I/O buffers.
177 In this case,
178 the driver must create one tag for the descriptor ring and a separate tag for
179 I/O buffers.
180 If a device has restrictions that are common to all DMA transactions
181 in addition to restrictions that differ between unrelated groups of
182 transactions,
183 the driver can first create a
184 .Dq parent
185 tag that decribes the common restrictions.
186 The per-group tags can then inherit these restrictions from this
187 .Dq parent
188 tag rather than having to list them explicitly when creating the per-group tags.
189 .Pp
190 A mapping structure
191 .Vt ( bus_dmamap_t )
192 represents a mapping of a memory region for DMA.
193 On systems with I/O MMUs,
194 the mapping structure tracks any I/O MMU entries used by a request.
195 For DMA requests that require bounce pages,
196 the mapping tracks the bounce pages used.
197 .Pp
198 To prepare for one or more DMA transactions,
199 a mapping must be bound to a memory region by calling one of the
200 .Fn bus_dmamap_load
201 functions.
202 These functions configure the mapping which can include programming entries
203 in an I/O MMU and/or allocating bounce pages.
204 An output of these functions
205 (either directly or indirectly by invoking a callback routine)
206 is the list of scatter/gather address ranges a consumer can pass to a DMA
207 engine to access the memory region.
208 When a mapping is no longer needed,
209 the mapping must be unloaded via
210 .Fn bus_dmamap_unload .
211 .Pp
212 Before and after each DMA transaction,
213 .Fn bus_dmamap_sync
214 must be used to ensure that the correct data is used by the DMA engine and
215 the CPU.
216 If a mapping uses bounce pages,
217 the sync operations copy data between the bounce pages and the memory region
218 bound to the mapping.
219 Sync operations also handle architecture-specific details such as CPU cache
220 flushing and CPU memory operation ordering.
221 .Sh STATIC VS DYNAMIC
222 .Nm
223 handles two types of DMA transactions: static and dynamic.
224 Static transactions are used with a long-lived memory region that is reused
225 for many transactions such as a descriptor ring.
226 Dynamic transactions are used for transfers to or from transient buffers
227 such as I/O buffers holding a network packet or disk block.
228 Each transaction type uses a different subset of the
229 .Nm
230 API.
231 .Ss Static Transactions
232 Static transactions use memory regions allocated by
233 .Nm .
234 Each static memory region is allocated by calling
235 .Fn bus_dmamem_alloc .
236 This function requires a valid tag describing the properties of the
237 DMA transactions to this region such as alignment or address restrictions.
238 Multiple regions can share a single tag if they share the same restrictions.
239 .Pp
240 .Fn bus_dmamem_alloc
241 allocates a memory region along with a mapping object.
242 The associated tag, memory region, and mapping object must then be passed to
243 .Fn bus_dmamap_load
244 to bind the mapping to the allocated region and obtain the
245 scatter/gather list.
246 .Pp
247 It is expected that
248 .Fn bus_dmamem_alloc
249 will attempt to allocate memory requiring less expensive sync operations
250 (for example, implementations should not allocate regions requiring bounce
251 pages),
252 but sync operations should still be used.
253 For example, a driver should use
254 .Fn bus_dmamap_sync
255 in an interrupt handler before reading descriptor ring entries written by the
256 device prior to the interrupt.
257 .Pp
258 When a consumer is finished with a memory region,
259 it should unload the mapping via
260 .Fn bus_dmamap_unload
261 and then release the memory region and mapping object via
262 .Fn bus_dmamem_free .
263 .Ss Dynamic Transactions
264 Dynamic transactions map memory regions provided by other parts of the system.
265 A tag must be created via
266 .Fn bus_dma_tag_create
267 to describe the DMA transactions to and from these memory regions,
268 and a pool of mapping objects must be allocated via
269 .Fn bus_dmamap_create
270 to track the mappings of any in-flight transactions.
271 .Pp
272 When a consumer wishes to schedule a transaction for a memory region,
273 the consumer must first obtain an unused mapping object from its pool
274 of mapping objects.
275 The memory region must be bound to the mapping object via one of the
276 .Fn bus_dmamap_load
277 functions.
278 Before scheduling the transaction,
279 the consumer should sync the memory region via
280 .Fn bus_dmamap_sync
281 with one or more of the
282 .Dq PRE
283 flags.
284 After the transaction has completed,
285 the consumer should sync the memory region via
286 .Fn bus_dmamap_sync
287 with one or more of the
288 .Dq POST
289 flags.
290 The mapping can then be unloaded via
291 .Fn bus_dmamap_unload ,
292 and the mapping object can be returned to the pool of unused mapping objects.
293 .Pp
294 When a consumer is no longer scheduling DMA transactions,
295 the mapping objects should be freed via
296 .Fn bus_dmamap_destroy ,
297 and the tag should be freed via
298 .Fn bus_dma_tag_destroy .
299 .Sh STRUCTURES AND TYPES
300 .Bl -tag -width indent
301 .It Vt bus_dma_tag_t
302 A machine-dependent (MD) opaque type that describes the
303 characteristics of a group of DMA transactions.
304 DMA tags are organized into a hierarchy, with each child
305 tag inheriting the restrictions of its parent.
306 This allows all devices along the path of DMA transactions
307 to contribute to the constraints of those transactions.
308 .It Vt bus_dma_template_t
309 A template structure for creating a
310 .Fa bus_dma_tag_t
311 from a set of defaults.
312 Once initialized with
313 .Fn bus_dma_template_init ,
314 a driver can over-ride individual fields to suit its needs.
315 The following fields have the indicated values:
316 .Bd -literal
317         alignment       1
318         boundary        0
319         lowaddr         BUS_SPACE_MAXADDR
320         highaddr        BUS_SPACE_MAXADDR
321         maxsize         BUS_SPACE_MAXSIZE
322         nsegments       BUS_SPACE_UNRESTRICTED
323         maxsegsize      BUS_SPACE_MAXSIZE
324         flags           0
325         lockfunc        NULL
326         lockfuncarg     NULL
327 .Ed
328 .Pp
329 Descriptions of each field are documented with
330 .Fn bus_dma_tag_create .
331 Note that the
332 .Fa filtfunc
333 and
334 .Fa filtfuncarg
335 attributes of the DMA tag are not supported with templates.
336 .It Vt bus_dma_filter_t
337 Client specified address filter having the format:
338 .Bl -tag -width indent
339 .It Ft int
340 .Fn "client_filter" "void *filtarg" "bus_addr_t testaddr"
341 .El
342 .Pp
343 Address filters can be specified during tag creation to allow
344 for devices whose DMA address restrictions cannot be specified
345 by a single window.
346 The
347 .Fa filtarg
348 argument is specified by the client during tag creation to be passed to all
349 invocations of the callback.
350 The
351 .Fa testaddr
352 argument contains a potential starting address of a DMA mapping.
353 The filter function operates on the set of addresses from
354 .Fa testaddr
355 to
356 .Ql trunc_page(testaddr) + PAGE_SIZE - 1 ,
357 inclusive.
358 The filter function should return zero if any mapping in this range
359 can be accommodated by the device and non-zero otherwise.
360 .It Vt bus_dma_segment_t
361 A machine-dependent type that describes individual
362 DMA segments.
363 It contains the following fields:
364 .Bd -literal
365         bus_addr_t      ds_addr;
366         bus_size_t      ds_len;
367 .Ed
368 .Pp
369 The
370 .Fa ds_addr
371 field contains the device visible address of the DMA segment, and
372 .Fa ds_len
373 contains the length of the DMA segment.
374 Although the DMA segments returned by a mapping call will adhere to
375 all restrictions necessary for a successful DMA operation, some conversion
376 (e.g.\& a conversion from host byte order to the device's byte order) is
377 almost always required when presenting segment information to the device.
378 .It Vt bus_dmamap_t
379 A machine-dependent opaque type describing an individual mapping.
380 One map is used for each memory allocation that will be loaded.
381 Maps can be reused once they have been unloaded.
382 Multiple maps can be associated with one DMA tag.
383 While the value of the map may evaluate to
384 .Dv NULL
385 on some platforms under certain conditions,
386 it should never be assumed that it will be
387 .Dv NULL
388 in all cases.
389 .It Vt bus_dmamap_callback_t
390 Client specified callback for receiving mapping information resulting from
391 the load of a
392 .Vt bus_dmamap_t
393 via
394 .Fn bus_dmamap_load ,
395 .Fn bus_dmamap_load_bio ,
396 .Fn bus_dmamap_load_ccb ,
397 or
398 .Fn bus_dmamap_load_crp .
399 Callbacks are of the format:
400 .Bl -tag -width indent
401 .It Ft void
402 .Fn "client_callback" "void *callback_arg" "bus_dma_segment_t *segs" \
403 "int nseg" "int error"
404 .El
405 .Pp
406 The
407 .Fa callback_arg
408 is the callback argument passed to dmamap load functions.
409 The
410 .Fa segs
411 and
412 .Fa nseg
413 arguments describe an array of
414 .Vt bus_dma_segment_t
415 structures that represent the mapping.
416 This array is only valid within the scope of the callback function.
417 The success or failure of the mapping is indicated by the
418 .Fa error
419 argument.
420 More information on the use of callbacks can be found in the
421 description of the individual dmamap load functions.
422 .It Vt bus_dmamap_callback2_t
423 Client specified callback for receiving mapping information resulting from
424 the load of a
425 .Vt bus_dmamap_t
426 via
427 .Fn bus_dmamap_load_uio
428 or
429 .Fn bus_dmamap_load_mbuf .
430 .Pp
431 Callback2s are of the format:
432 .Bl -tag -width indent
433 .It Ft void
434 .Fn "client_callback2" "void *callback_arg" "bus_dma_segment_t *segs" \
435 "int nseg" "bus_size_t mapsize" "int error"
436 .El
437 .Pp
438 Callback2's behavior is the same as
439 .Vt bus_dmamap_callback_t
440 with the addition that the length of the data mapped is provided via
441 .Fa mapsize .
442 .It Vt bus_dmasync_op_t
443 Memory synchronization operation specifier.
444 Bus DMA requires explicit synchronization of memory with its device
445 visible mapping in order to guarantee memory coherency.
446 The
447 .Vt bus_dmasync_op_t
448 allows the type of DMA operation that will be or has been performed
449 to be communicated to the system so that the correct coherency measures
450 are taken.
451 The operations are represented as bitfield flags that can be combined together,
452 though it only makes sense to combine PRE flags or POST flags, not both.
453 See the
454 .Fn bus_dmamap_sync
455 description below for more details on how to use these operations.
456 .Pp
457 All operations specified below are performed from the host memory point of view,
458 where a read implies data coming from the device to the host memory, and a write
459 implies data going from the host memory to the device.
460 Alternatively, the operations can be thought of in terms of driver operations,
461 where reading a network packet or storage sector corresponds to a read operation
462 in
463 .Nm .
464 .Bl -tag -width ".Dv BUS_DMASYNC_POSTWRITE"
465 .It Dv BUS_DMASYNC_PREREAD
466 Perform any synchronization required prior to an update of host memory by the
467 device.
468 .It Dv BUS_DMASYNC_PREWRITE
469 Perform any synchronization required after an update of host memory by the CPU
470 and prior to device access to host memory.
471 .It Dv BUS_DMASYNC_POSTREAD
472 Perform any synchronization required after an update of host memory by the
473 device and prior to CPU access to host memory.
474 .It Dv BUS_DMASYNC_POSTWRITE
475 Perform any synchronization required after device access to host memory.
476 .El
477 .It Vt bus_dma_lock_t
478 Client specified lock/mutex manipulation method.
479 This will be called from
480 within busdma whenever a client lock needs to be manipulated.
481 In its current form, the function will be called immediately before
482 the callback for a DMA load operation that has been deferred with
483 .Dv BUS_DMA_LOCK
484 and immediately after with
485 .Dv BUS_DMA_UNLOCK .
486 If the load operation does not need to be deferred, then it
487 will not be called since the function loading the map should
488 be holding the appropriate locks.
489 This method is of the format:
490 .Bl -tag -width indent
491 .It Ft void
492 .Fn "lockfunc" "void *lockfunc_arg" "bus_dma_lock_op_t op"
493 .El
494 .Pp
495 The
496 .Fa lockfuncarg
497 argument is specified by the client during tag creation to be passed to all
498 invocations of the callback.
499 The
500 .Fa op
501 argument specifies the lock operation to perform.
502 .Pp
503 Two
504 .Vt lockfunc
505 implementations are provided for convenience.
506 .Fn busdma_lock_mutex
507 performs standard mutex operations on the sleep mutex provided via
508 .Fa lockfuncarg .
509 .Fn dflt_lock
510 will generate a system panic if it is called.
511 It is substituted into the tag when
512 .Fa lockfunc
513 is passed as
514 .Dv NULL
515 to
516 .Fn bus_dma_tag_create
517 and is useful for tags that should not be used with deferred load operations.
518 .It Vt bus_dma_lock_op_t
519 Operations to be performed by the client-specified
520 .Fn lockfunc .
521 .Bl -tag -width ".Dv BUS_DMA_UNLOCK"
522 .It Dv BUS_DMA_LOCK
523 Acquires and/or locks the client locking primitive.
524 .It Dv BUS_DMA_UNLOCK
525 Releases and/or unlocks the client locking primitive.
526 .El
527 .El
528 .Sh FUNCTIONS
529 .Bl -tag -width indent
530 .It Fn bus_dma_tag_create "parent" "alignment" "boundary" "lowaddr" \
531 "highaddr" "*filtfunc" "*filtfuncarg" "maxsize" "nsegments" "maxsegsz" \
532 "flags" "lockfunc" "lockfuncarg" "*dmat"
533 Allocates a DMA tag, and initializes it according to
534 the arguments provided:
535 .Bl -tag -width ".Fa filtfuncarg"
536 .It Fa parent
537 A parent tag from which to inherit restrictions.
538 The restrictions passed in other arguments can only further tighten the
539 restrictions inherited from the parent tag.
540 .Pp
541 All tags created by a device driver must inherit from the tag returned by
542 .Fn bus_get_dma_tag
543 to honor restrictions between the parent bridge, CPU memory, and the
544 device.
545 .It Fa alignment
546 Alignment constraint, in bytes, of any mappings created using this tag.
547 The alignment must be a power of 2.
548 Hardware that can DMA starting at any address would specify
549 .Em 1
550 for byte alignment.
551 Hardware requiring DMA transfers to start on a multiple of 4K
552 would specify
553 .Em 4096 .
554 .It Fa boundary
555 Boundary constraint, in bytes, of the target DMA memory region.
556 The boundary indicates the set of addresses, all multiples of the
557 boundary argument, that cannot be crossed by a single
558 .Vt bus_dma_segment_t .
559 The boundary must be a power of 2 and must be no smaller than the
560 maximum segment size.
561 .Ql 0
562 indicates that there are no boundary restrictions.
563 .It Fa lowaddr , highaddr
564 Bounds of the window of bus address space that
565 .Em cannot
566 be directly accessed by the device.
567 The window contains all addresses greater than
568 .Fa lowaddr
569 and less than or equal to
570 .Fa highaddr .
571 For example, a device incapable of DMA above 4GB, would specify a
572 .Fa highaddr
573 of
574 .Dv BUS_SPACE_MAXADDR
575 and a
576 .Fa lowaddr
577 of
578 .Dv BUS_SPACE_MAXADDR_32BIT .
579 Similarly a device that can only perform DMA to addresses below
580 16MB would specify a
581 .Fa highaddr
582 of
583 .Dv BUS_SPACE_MAXADDR
584 and a
585 .Fa lowaddr
586 of
587 .Dv BUS_SPACE_MAXADDR_24BIT .
588 Some implementations require that some region of device visible
589 address space, overlapping available host memory, be outside the
590 window.
591 This area of
592 .Ql safe memory
593 is used to bounce requests that would otherwise conflict with
594 the exclusion window.
595 .It Fa filtfunc
596 Optional filter function (may be
597 .Dv NULL )
598 to be called for any attempt to
599 map memory into the window described by
600 .Fa lowaddr
601 and
602 .Fa highaddr .
603 A filter function is only required when the single window described
604 by
605 .Fa lowaddr
606 and
607 .Fa highaddr
608 cannot adequately describe the constraints of the device.
609 The filter function will be called for every machine page
610 that overlaps the exclusion window.
611 .It Fa filtfuncarg
612 Argument passed to all calls to the filter function for this tag.
613 May be
614 .Dv NULL .
615 .It Fa maxsize
616 Maximum size, in bytes, of the sum of all segment lengths in a given
617 DMA mapping associated with this tag.
618 .It Fa nsegments
619 Number of discontinuities (scatter/gather segments) allowed
620 in a DMA mapped region.
621 .It Fa maxsegsz
622 Maximum size, in bytes, of a segment in any DMA mapped region associated
623 with
624 .Fa dmat .
625 .It Fa flags
626 Are as follows:
627 .Bl -tag -width ".Dv BUS_DMA_ALLOCNOW"
628 .It Dv BUS_DMA_ALLOCNOW
629 Pre-allocate enough resources to handle at least one map load operation on
630 this tag.
631 If sufficient resources are not available,
632 .Er ENOMEM
633 is returned.
634 This should not be used for tags that only describe buffers that will be
635 allocated with
636 .Fn bus_dmamem_alloc .
637 Also, due to resource sharing with other tags, this flag does not guarantee
638 that resources will be allocated or reserved exclusively for this tag.
639 It should be treated only as a minor optimization.
640 .It Dv BUS_DMA_COHERENT
641 Indicate that the DMA engine and CPU are cache-coherent.
642 Cached memory may be used to back allocations created by
643 .Fn bus_dmamem_alloc .
644 For
645 .Fn bus_dma_tag_create ,
646 the
647 .Dv BUS_DMA_COHERENT
648 flag is currently implemented on arm64.
649 .El
650 .It Fa lockfunc
651 Optional lock manipulation function (may be
652 .Dv NULL )
653 to be called when busdma
654 needs to manipulate a lock on behalf of the client.
655 If
656 .Dv NULL
657 is specified,
658 .Fn dflt_lock
659 is used.
660 .It Fa lockfuncarg
661 Optional argument to be passed to the function specified by
662 .Fa lockfunc .
663 .It Fa dmat
664 Pointer to a bus_dma_tag_t where the resulting DMA tag will
665 be stored.
666 .El
667 .Pp
668 Returns
669 .Er ENOMEM
670 if sufficient memory is not available for tag creation
671 or allocating mapping resources.
672 .It Fn bus_dma_tag_destroy "dmat"
673 Deallocate the DMA tag
674 .Fa dmat
675 that was created by
676 .Fn bus_dma_tag_create .
677 .Pp
678 Returns
679 .Er EBUSY
680 if any DMA maps remain associated with
681 .Fa dmat
682 or
683 .Ql 0
684 on success.
685 .It Fn bus_dma_template_init "*template" "parent"
686 Initializes a
687 .Fa bus_dma_template_t
688 structure and associates it with an optional 
689 .Fa parent .
690 The
691 .Fa parent
692 argument may be NULL.
693 .It Fn bus_dma_template_tag "*template" "*dmat"
694 Unpacks a template into a tag, and returns the tag via the
695 .Fa dmat .
696 All return values are identical to
697 .Fn bus_dma_tag_create .
698 .It Fn bus_dma_template_clone "*template" "dmat"
699 Clones the fields from a tag to a template.
700 This is useful for cloning tags when paired with
701 .Fn bus_dma_template_tag .
702 A template that is filled in as a clone does not need to be initialized
703 first.
704 .It Fn bus_dmamap_create "dmat" "flags" "*mapp"
705 Allocates and initializes a DMA map.
706 Arguments are as follows:
707 .Bl -tag -width ".Fa nsegments"
708 .It Fa dmat
709 DMA tag.
710 .It Fa flags
711 Are as follows:
712 .Bl -tag -width ".Dv BUS_DMA_COHERENT"
713 .It Dv BUS_DMA_COHERENT
714 Attempt to map the memory loaded with this map such that cache sync
715 operations are as cheap as possible.
716 This flag is typically set on maps when the memory loaded with these will
717 be accessed by both a CPU and a DMA engine, frequently such as control data
718 and as opposed to streamable data such as receive and transmit buffers.
719 Use of this flag does not remove the requirement of using
720 .Fn bus_dmamap_sync ,
721 but it may reduce the cost of performing these operations.
722 .El
723 .It Fa mapp
724 Pointer to a
725 .Vt bus_dmamap_t
726 where the resulting DMA map will be stored.
727 .El
728 .Pp
729 Returns
730 .Er ENOMEM
731 if sufficient memory is not available for creating the
732 map or allocating mapping resources.
733 .It Fn bus_dmamap_destroy "dmat" "map"
734 Frees all resources associated with a given DMA map.
735 Arguments are as follows:
736 .Bl -tag -width ".Fa dmat"
737 .It Fa dmat
738 DMA tag used to allocate
739 .Fa map .
740 .It Fa map
741 The DMA map to destroy.
742 .El
743 .Pp
744 Returns
745 .Er EBUSY
746 if a mapping is still active for
747 .Fa map .
748 .It Fn bus_dmamap_load "dmat" "map" "buf" "buflen" "*callback" \
749 "callback_arg" "flags"
750 Creates a mapping in device visible address space of
751 .Fa buflen
752 bytes of
753 .Fa buf ,
754 associated with the DMA map
755 .Fa map .
756 This call will always return immediately and will not block for any reason.
757 Arguments are as follows:
758 .Bl -tag -width ".Fa buflen"
759 .It Fa dmat
760 DMA tag used to allocate
761 .Fa map .
762 .It Fa map
763 A DMA map without a currently active mapping.
764 .It Fa buf
765 A kernel virtual address pointer to a contiguous (in KVA) buffer, to be
766 mapped into device visible address space.
767 .It Fa buflen
768 The size of the buffer.
769 .It Fa callback Fa callback_arg
770 The callback function, and its argument.
771 This function is called once sufficient mapping resources are available for
772 the DMA operation.
773 If resources are temporarily unavailable, this function will be deferred until
774 later, but the load operation will still return immediately to the caller.
775 Thus, callers should not assume that the callback will be called before the
776 load returns, and code should be structured appropriately to handle this.
777 See below for specific flags and error codes that control this behavior.
778 .It Fa flags
779 Are as follows:
780 .Bl -tag -width ".Dv BUS_DMA_NOWAIT"
781 .It Dv BUS_DMA_NOWAIT
782 The load should not be deferred in case of insufficient mapping resources,
783 and instead should return immediately with an appropriate error.
784 .It Dv BUS_DMA_NOCACHE
785 The generated transactions to and from the virtual page are non-cacheable.
786 .El
787 .El
788 .Pp
789 Return values to the caller are as follows:
790 .Bl -tag -width ".Er EINPROGRESS"
791 .It 0
792 The callback has been called and completed.
793 The status of the mapping has been delivered to the callback.
794 .It Er EINPROGRESS
795 The mapping has been deferred for lack of resources.
796 The callback will be called as soon as resources are available.
797 Callbacks are serviced in FIFO order.
798 .Pp
799 Note that subsequent load operations for the same tag that do not require
800 extra resources will still succeed.
801 This may result in out-of-order processing of requests.
802 If the caller requires the order of requests to be preserved,
803 then the caller is required to stall subsequent requests until a pending
804 request's callback is invoked.
805 .It Er ENOMEM
806 The load request has failed due to insufficient resources, and the caller
807 specifically used the
808 .Dv BUS_DMA_NOWAIT
809 flag.
810 .It Er EINVAL
811 The load request was invalid.
812 The callback has been called and has been provided the same error.
813 This error value may indicate that
814 .Fa dmat ,
815 .Fa map ,
816 .Fa buf ,
817 or
818 .Fa callback
819 were invalid, or
820 .Fa buflen
821 was larger than the
822 .Fa maxsize
823 argument used to create the dma tag
824 .Fa dmat .
825 .El
826 .Pp
827 When the callback is called, it is presented with an error value
828 indicating the disposition of the mapping.
829 Error may be one of the following:
830 .Bl -tag -width ".Er EINPROGRESS"
831 .It 0
832 The mapping was successful and the
833 .Fa dm_segs
834 callback argument contains an array of
835 .Vt bus_dma_segment_t
836 elements describing the mapping.
837 This array is only valid during the scope of the callback function.
838 .It Er EFBIG
839 A mapping could not be achieved within the segment constraints provided
840 in the tag even though the requested allocation size was less than maxsize.
841 .El
842 .It Fn bus_dmamap_load_bio "dmat" "map" "bio" "callback" "callback_arg" "flags"
843 This is a variation of
844 .Fn bus_dmamap_load
845 which maps buffers pointed to by
846 .Fa bio
847 for DMA transfers.
848 .Fa bio
849 may point to either a mapped or unmapped buffer.
850 .It Fn bus_dmamap_load_ccb "dmat" "map" "ccb" "callback" "callback_arg" "flags"
851 This is a variation of
852 .Fn bus_dmamap_load
853 which maps data pointed to by
854 .Fa ccb
855 for DMA transfers.
856 The data for
857 .Fa ccb
858 may be any of the following types:
859 .Bl -tag -width ".Er CAM_DATA_SG_PADDR"
860 .It CAM_DATA_VADDR
861 The data is a single KVA buffer.
862 .It CAM_DATA_PADDR
863 The data is a single bus address range.
864 .It CAM_DATA_SG
865 The data is a scatter/gather list of KVA buffers.
866 .It CAM_DATA_SG_PADDR
867 The data is a scatter/gather list of bus address ranges.
868 .It CAM_DATA_BIO
869 The data is contained in a
870 .Vt struct bio
871 attached to the CCB.
872 .El
873 .Pp
874 .Fn bus_dmamap_load_ccb
875 supports the following CCB XPT function codes:
876 .Pp
877 .Bl -item -offset indent -compact
878 .It
879 XPT_ATA_IO
880 .It
881 XPT_CONT_TARGET_IO
882 .It
883 XPT_SCSI_IO
884 .El
885 .It Fn bus_dmamap_load_crp "dmat" "map" "crp" "callback" "callback_arg" "flags"
886 This is a variation of
887 .Fn bus_dmamap_load
888 which maps buffers pointed to by
889 .Fa crp
890 for DMA transfers.
891 The
892 .Dv BUS_DMA_NOWAIT
893 flag is implied, thus no callback deferral will happen.
894 .It Fn bus_dmamap_load_mbuf "dmat" "map" "mbuf" "callback2" "callback_arg" \
895 "flags"
896 This is a variation of
897 .Fn bus_dmamap_load
898 which maps mbuf chains
899 for DMA transfers.
900 A
901 .Vt bus_size_t
902 argument is also passed to the callback routine, which
903 contains the mbuf chain's packet header length.
904 The
905 .Dv BUS_DMA_NOWAIT
906 flag is implied, thus no callback deferral will happen.
907 .Pp
908 Mbuf chains are assumed to be in kernel virtual address space.
909 .Pp
910 Beside the error values listed for
911 .Fn bus_dmamap_load ,
912 .Er EINVAL
913 will be returned if the size of the mbuf chain exceeds the maximum limit of the
914 DMA tag.
915 .It Fn bus_dmamap_load_mbuf_sg "dmat" "map" "mbuf" "segs" "nsegs" "flags"
916 This is just like
917 .Fn bus_dmamap_load_mbuf
918 except that it returns immediately without calling a callback function.
919 It is provided for efficiency.
920 The scatter/gather segment array
921 .Va segs
922 is provided by the caller and filled in directly by the function.
923 The
924 .Va nsegs
925 argument is returned with the number of segments filled in.
926 Returns the same errors as
927 .Fn bus_dmamap_load_mbuf .
928 .It Fn bus_dmamap_load_uio "dmat" "map" "uio" "callback2" "callback_arg" "flags"
929 This is a variation of
930 .Fn bus_dmamap_load
931 which maps buffers pointed to by
932 .Fa uio
933 for DMA transfers.
934 A
935 .Vt bus_size_t
936 argument is also passed to the callback routine, which contains the size of
937 .Fa uio ,
938 i.e.
939 .Fa uio->uio_resid .
940 The
941 .Dv BUS_DMA_NOWAIT
942 flag is implied, thus no callback deferral will happen.
943 Returns the same errors as
944 .Fn bus_dmamap_load .
945 .Pp
946 If
947 .Fa uio->uio_segflg
948 is
949 .Dv UIO_USERSPACE ,
950 then it is assumed that the buffer,
951 .Fa uio
952 is in
953 .Fa "uio->uio_td->td_proc" Ns 's
954 address space.
955 User space memory must be in-core and wired prior to attempting a map
956 load operation.
957 Pages may be locked using
958 .Xr vslock 9 .
959 .It Fn bus_dmamap_unload "dmat" "map"
960 Unloads a DMA map.
961 Arguments are as follows:
962 .Bl -tag -width ".Fa dmam"
963 .It Fa dmat
964 DMA tag used to allocate
965 .Fa map .
966 .It Fa map
967 The DMA map that is to be unloaded.
968 .El
969 .Pp
970 .Fn bus_dmamap_unload
971 will not perform any implicit synchronization of DMA buffers.
972 This must be done explicitly by a call to
973 .Fn bus_dmamap_sync
974 prior to unloading the map.
975 .It Fn bus_dmamap_sync "dmat" "map" "op"
976 Performs synchronization of a device visible mapping with the CPU visible
977 memory referenced by that mapping.
978 Arguments are as follows:
979 .Bl -tag -width ".Fa dmat"
980 .It Fa dmat
981 DMA tag used to allocate
982 .Fa map .
983 .It Fa map
984 The DMA mapping to be synchronized.
985 .It Fa op
986 Type of synchronization operation to perform.
987 See the definition of
988 .Vt bus_dmasync_op_t
989 for a description of the acceptable values for
990 .Fa op .
991 .El
992 .Pp
993 The
994 .Fn bus_dmamap_sync
995 function
996 is the method used to ensure that CPU's and device's direct
997 memory access (DMA) to shared
998 memory is coherent.
999 For example, the CPU might be used to set up the contents of a buffer
1000 that is to be made available to a device.
1001 To ensure that the data are visible via the device's mapping of that
1002 memory, the buffer must be loaded and a DMA sync operation of
1003 .Dv BUS_DMASYNC_PREWRITE
1004 must be performed after the CPU has updated the buffer and before the device
1005 access is initiated.
1006 If the CPU modifies this buffer again later, another
1007 .Dv BUS_DMASYNC_PREWRITE
1008 sync operation must be performed before an additional device
1009 access.
1010 Conversely, suppose a device updates memory that is to be read by a CPU.
1011 In this case, the buffer must be loaded, and a DMA sync operation of
1012 .Dv BUS_DMASYNC_PREREAD
1013 must be performed before the device access is initiated.
1014 The CPU will only be able to see the results of this memory update
1015 once the DMA operation has completed and a
1016 .Dv BUS_DMASYNC_POSTREAD
1017 sync operation has been performed.
1018 .Pp
1019 If read and write operations are not preceded and followed by the
1020 appropriate synchronization operations, behavior is undefined.
1021 .It Fn bus_dmamem_alloc "dmat" "**vaddr" "flags" "*mapp"
1022 Allocates memory that is mapped into KVA at the address returned
1023 in
1024 .Fa vaddr
1025 and that is permanently loaded into the newly created
1026 .Vt bus_dmamap_t
1027 returned via
1028 .Fa mapp .
1029 Arguments are as follows:
1030 .Bl -tag -width ".Fa alignment"
1031 .It Fa dmat
1032 DMA tag describing the constraints of the DMA mapping.
1033 .It Fa vaddr
1034 Pointer to a pointer that will hold the returned KVA mapping of
1035 the allocated region.
1036 .It Fa flags
1037 Flags are defined as follows:
1038 .Bl -tag -width ".Dv BUS_DMA_NOWAIT"
1039 .It Dv BUS_DMA_WAITOK
1040 The routine can safely wait (sleep) for resources.
1041 .It Dv BUS_DMA_NOWAIT
1042 The routine is not allowed to wait for resources.
1043 If resources are not available,
1044 .Dv ENOMEM
1045 is returned.
1046 .It Dv BUS_DMA_COHERENT
1047 Attempt to map this memory in a coherent fashion.
1048 See
1049 .Fn bus_dmamap_create
1050 above for a description of this flag.
1051 For
1052 .Fn bus_dmamem_alloc ,
1053 the
1054 .Dv BUS_DMA_COHERENT
1055 flag is currently implemented on arm and arm64.
1056 .It Dv BUS_DMA_ZERO
1057 Causes the allocated memory to be set to all zeros.
1058 .It Dv BUS_DMA_NOCACHE
1059 The allocated memory will not be cached in the processor caches.
1060 All memory accesses appear on the bus and are executed
1061 without reordering.
1062 For
1063 .Fn bus_dmamem_alloc ,
1064 the
1065 .Dv BUS_DMA_NOCACHE
1066 flag is currently implemented on amd64 and i386 where it results in the
1067 Strong Uncacheable PAT to be set for the allocated virtual address range.
1068 .El
1069 .It Fa mapp
1070 Pointer to a
1071 .Vt bus_dmamap_t
1072 where the resulting DMA map will be stored.
1073 .El
1074 .Pp
1075 The size of memory to be allocated is
1076 .Fa maxsize
1077 as specified in the call to
1078 .Fn bus_dma_tag_create
1079 for
1080 .Fa dmat .
1081 .Pp
1082 The current implementation of
1083 .Fn bus_dmamem_alloc
1084 will allocate all requests as a single segment.
1085 .Pp
1086 An initial load operation is required to obtain the bus address of the allocated
1087 memory, and an unload operation is required before freeing the memory, as
1088 described below in
1089 .Fn bus_dmamem_free .
1090 Maps are automatically handled by this function and should not be explicitly
1091 allocated or destroyed.
1092 .Pp
1093 Although an explicit load is not required for each access to the memory
1094 referenced by the returned map, the synchronization requirements
1095 as described in the
1096 .Fn bus_dmamap_sync
1097 section still apply and should be used to achieve portability on architectures
1098 without coherent buses.
1099 .Pp
1100 Returns
1101 .Er ENOMEM
1102 if sufficient memory is not available for completing
1103 the operation.
1104 .It Fn bus_dmamem_free "dmat" "*vaddr" "map"
1105 Frees memory previously allocated by
1106 .Fn bus_dmamem_alloc .
1107 Any mappings
1108 will be invalidated.
1109 Arguments are as follows:
1110 .Bl -tag -width ".Fa vaddr"
1111 .It Fa dmat
1112 DMA tag.
1113 .It Fa vaddr
1114 Kernel virtual address of the memory.
1115 .It Fa map
1116 DMA map to be invalidated.
1117 .El
1118 .El
1119 .Sh RETURN VALUES
1120 Behavior is undefined if invalid arguments are passed to
1121 any of the above functions.
1122 If sufficient resources cannot be allocated for a given
1123 transaction,
1124 .Er ENOMEM
1125 is returned.
1126 All
1127 routines that are not of type
1128 .Vt void
1129 will return 0 on success or an error
1130 code on failure as discussed above.
1131 .Pp
1132 All
1133 .Vt void
1134 routines will succeed if provided with valid arguments.
1135 .Sh LOCKING
1136 Two locking protocols are used by
1137 .Nm .
1138 The first is a private global lock that is used to synchronize access to the
1139 bounce buffer pool on the architectures that make use of them.
1140 This lock is strictly a leaf lock that is only used internally to
1141 .Nm
1142 and is not exposed to clients of the API.
1143 .Pp
1144 The second protocol involves protecting various resources stored in the tag.
1145 Since almost all
1146 .Nm
1147 operations are done through requests from the driver that created the tag,
1148 the most efficient way to protect the tag resources is through the lock that
1149 the driver uses.
1150 In cases where
1151 .Nm
1152 acts on its own without being called by the driver, the lock primitive
1153 specified in the tag is acquired and released automatically.
1154 An example of this is when the
1155 .Fn bus_dmamap_load
1156 callback function is called from a deferred context instead of the driver
1157 context.
1158 This means that certain
1159 .Nm
1160 functions must always be called with the same lock held that is specified in the
1161 tag.
1162 These functions include:
1163 .Pp
1164 .Bl -item -offset indent -compact
1165 .It
1166 .Fn bus_dmamap_load
1167 .It
1168 .Fn bus_dmamap_load_bio
1169 .It
1170 .Fn bus_dmamap_load_ccb
1171 .It
1172 .Fn bus_dmamap_load_mbuf
1173 .It
1174 .Fn bus_dmamap_load_mbuf_sg
1175 .It
1176 .Fn bus_dmamap_load_uio
1177 .It
1178 .Fn bus_dmamap_unload
1179 .It
1180 .Fn bus_dmamap_sync
1181 .El
1182 .Pp
1183 There is one exception to this rule.
1184 It is common practice to call some of these functions during driver start-up
1185 without any locks held.
1186 So long as there is a guarantee of no possible concurrent use of the tag by
1187 different threads during this operation, it is safe to not hold a lock for
1188 these functions.
1189 .Pp
1190 Certain
1191 .Nm
1192 operations should not be called with the driver lock held, either because
1193 they are already protected by an internal lock, or because they might sleep
1194 due to memory or resource allocation.
1195 The following functions must not be
1196 called with any non-sleepable locks held:
1197 .Pp
1198 .Bl -item -offset indent -compact
1199 .It
1200 .Fn bus_dma_tag_create
1201 .It
1202 .Fn bus_dmamap_create
1203 .It
1204 .Fn bus_dmamem_alloc
1205 .El
1206 .Pp
1207 All other functions do not have a locking protocol and can thus be
1208 called with or without any system or driver locks held.
1209 .Sh SEE ALSO
1210 .Xr devclass 9 ,
1211 .Xr device 9 ,
1212 .Xr driver 9 ,
1213 .Xr rman 9 ,
1214 .Xr vslock 9
1215 .Pp
1216 .Rs
1217 .%A "Jason R. Thorpe"
1218 .%T "A Machine-Independent DMA Framework for NetBSD"
1219 .%J "Proceedings of the Summer 1998 USENIX Technical Conference"
1220 .%Q "USENIX Association"
1221 .%D "June 1998"
1222 .Re
1223 .Sh HISTORY
1224 The
1225 .Nm
1226 interface first appeared in
1227 .Nx 1.3 .
1228 .Pp
1229 The
1230 .Nm
1231 API was adopted from
1232 .Nx
1233 for use in the CAM SCSI subsystem.
1234 The alterations to the original API were aimed to remove the need for
1235 a
1236 .Vt bus_dma_segment_t
1237 array stored in each
1238 .Vt bus_dmamap_t
1239 while allowing callers to queue up on scarce resources.
1240 .Sh AUTHORS
1241 The
1242 .Nm
1243 interface was designed and implemented by
1244 .An Jason R. Thorpe
1245 of the Numerical Aerospace Simulation Facility, NASA Ames Research Center.
1246 Additional input on the
1247 .Nm
1248 design was provided by
1249 .An -nosplit
1250 .An Chris Demetriou ,
1251 .An Charles Hannum ,
1252 .An Ross Harvey ,
1253 .An Matthew Jacob ,
1254 .An Jonathan Stone ,
1255 and
1256 .An Matt Thomas .
1257 .Pp
1258 The
1259 .Nm
1260 interface in
1261 .Fx
1262 benefits from the contributions of
1263 .An Justin T. Gibbs ,
1264 .An Peter Wemm ,
1265 .An Doug Rabson ,
1266 .An Matthew N. Dodd ,
1267 .An Sam Leffler ,
1268 .An Maxime Henrion ,
1269 .An Jake Burkholder ,
1270 .An Takahashi Yoshihiro ,
1271 .An Scott Long
1272 and many others.
1273 .Pp
1274 This manual page was written by
1275 .An Hiten M. Pandya
1276 and
1277 .An Justin T. Gibbs .