xref: /freebsd/share/man/man9/bus_dma.9 (revision c5fda9bac0325eb8c5b447717862d279006f318f)
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 July 17, 2013
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_dmamap_create ,
64.Nm bus_dmamap_destroy ,
65.Nm bus_dmamap_load ,
66.Nm bus_dmamap_load_bio ,
67.Nm bus_dmamap_load_ccb ,
68.Nm bus_dmamap_load_mbuf ,
69.Nm bus_dmamap_load_mbuf_sg ,
70.Nm bus_dmamap_load_uio ,
71.Nm bus_dmamap_unload ,
72.Nm bus_dmamap_sync ,
73.Nm bus_dmamem_alloc ,
74.Nm bus_dmamem_free
75.Nd Bus and Machine Independent DMA Mapping Interface
76.Sh SYNOPSIS
77.In machine/bus.h
78.Ft int
79.Fn bus_dma_tag_create "bus_dma_tag_t parent" "bus_size_t alignment" \
80"bus_addr_t boundary" "bus_addr_t lowaddr" "bus_addr_t highaddr" \
81"bus_dma_filter_t *filtfunc" "void *filtfuncarg" "bus_size_t maxsize" \
82"int nsegments" "bus_size_t maxsegsz" "int flags" "bus_dma_lock_t *lockfunc" \
83"void *lockfuncarg" "bus_dma_tag_t *dmat"
84.Ft int
85.Fn bus_dma_tag_destroy "bus_dma_tag_t dmat"
86.Ft int
87.Fn bus_dmamap_create "bus_dma_tag_t dmat" "int flags" "bus_dmamap_t *mapp"
88.Ft int
89.Fn bus_dmamap_destroy "bus_dma_tag_t dmat" "bus_dmamap_t map"
90.Ft int
91.Fn bus_dmamap_load "bus_dma_tag_t dmat" "bus_dmamap_t map" "void *buf" \
92"bus_size_t buflen" "bus_dmamap_callback_t *callback" "void *callback_arg" \
93"int flags"
94.Ft int
95.Fn bus_dmamap_load_bio "bus_dma_tag_t dmat" "bus_dmamap_t map" \
96"struct bio *bio" "bus_dmamap_callback_t *callback" "void *callback_arg" \
97"int flags"
98.Ft int
99.Fn bus_dmamap_load_ccb "bus_dma_tag_t dmat" "bus_dmamap_t map" \
100"union ccb *ccb" "bus_dmamap_callback_t *callback" "void *callback_arg" \
101"int flags"
102.Ft int
103.Fn bus_dmamap_load_mbuf "bus_dma_tag_t dmat" "bus_dmamap_t map" \
104"struct mbuf *mbuf" "bus_dmamap_callback2_t *callback" "void *callback_arg" \
105"int flags"
106.Ft int
107.Fn bus_dmamap_load_mbuf_sg "bus_dma_tag_t dmat" "bus_dmamap_t map" \
108"struct mbuf *mbuf" "bus_dma_segment_t *segs" "int *nsegs" "int flags"
109.Ft int
110.Fn bus_dmamap_load_uio "bus_dma_tag_t dmat" "bus_dmamap_t map" \
111"struct uio *uio" "bus_dmamap_callback2_t *callback" "void *callback_arg" \
112"int flags"
113.Ft void
114.Fn bus_dmamap_unload "bus_dma_tag_t dmat" "bus_dmamap_t map"
115.Ft void
116.Fn bus_dmamap_sync "bus_dma_tag_t dmat" "bus_dmamap_t map" \
117"op"
118.Ft int
119.Fn bus_dmamem_alloc "bus_dma_tag_t dmat" "void **vaddr" \
120"int flags" "bus_dmamap_t *mapp"
121.Ft void
122.Fn bus_dmamem_free "bus_dma_tag_t dmat" "void *vaddr" \
123"bus_dmamap_t map"
124.Sh DESCRIPTION
125Direct Memory Access (DMA) is a method of transferring data
126without involving the CPU, thus providing higher performance.
127A DMA transaction can be achieved between device to memory,
128device to device, or memory to memory.
129.Pp
130The
131.Nm
132API is a bus, device, and machine-independent (MI) interface to
133DMA mechanisms.
134It provides the client with flexibility and simplicity by
135abstracting machine dependent issues like setting up
136DMA mappings, handling cache issues, bus specific features
137and limitations.
138.Sh STRUCTURES AND TYPES
139.Bl -tag -width indent
140.It Vt bus_dma_tag_t
141A machine-dependent (MD) opaque type that describes the
142characteristics of DMA transactions.
143DMA tags are organized into a hierarchy, with each child
144tag inheriting the restrictions of its parent.
145This allows all devices along the path of DMA transactions
146to contribute to the constraints of those transactions.
147.It Vt bus_dma_filter_t
148Client specified address filter having the format:
149.Bl -tag -width indent
150.It Ft int
151.Fn "client_filter" "void *filtarg" "bus_addr_t testaddr"
152.El
153.Pp
154Address filters can be specified during tag creation to allow
155for devices whose DMA address restrictions cannot be specified
156by a single window.
157The
158.Fa filtarg
159argument is specified by the client during tag creation to be passed to all
160invocations of the callback.
161The
162.Fa testaddr
163argument contains a potential starting address of a DMA mapping.
164The filter function operates on the set of addresses from
165.Fa testaddr
166to
167.Ql trunc_page(testaddr) + PAGE_SIZE - 1 ,
168inclusive.
169The filter function should return zero if any mapping in this range
170can be accommodated by the device and non-zero otherwise.
171.It Vt bus_dma_segment_t
172A machine-dependent type that describes individual
173DMA segments.
174It contains the following fields:
175.Bd -literal
176	bus_addr_t	ds_addr;
177	bus_size_t	ds_len;
178.Ed
179.Pp
180The
181.Fa ds_addr
182field contains the device visible address of the DMA segment, and
183.Fa ds_len
184contains the length of the DMA segment.
185Although the DMA segments returned by a mapping call will adhere to
186all restrictions necessary for a successful DMA operation, some conversion
187(e.g.\& a conversion from host byte order to the device's byte order) is
188almost always required when presenting segment information to the device.
189.It Vt bus_dmamap_t
190A machine-dependent opaque type describing an individual mapping.
191One map is used for each memory allocation that will be loaded.
192Maps can be reused once they have been unloaded.
193Multiple maps can be associated with one DMA tag.
194While the value of the map may evaluate to
195.Dv NULL
196on some platforms under certain conditions,
197it should never be assumed that it will be
198.Dv NULL
199in all cases.
200.It Vt bus_dmamap_callback_t
201Client specified callback for receiving mapping information resulting from
202the load of a
203.Vt bus_dmamap_t
204via
205.Fn bus_dmamap_load ,
206.Fn bus_dmamap_load_bio
207or
208.Fn bus_dmamap_load_ccb .
209Callbacks are of the format:
210.Bl -tag -width indent
211.It Ft void
212.Fn "client_callback" "void *callback_arg" "bus_dma_segment_t *segs" \
213"int nseg" "int error"
214.El
215.Pp
216The
217.Fa callback_arg
218is the callback argument passed to dmamap load functions.
219The
220.Fa segs
221and
222.Fa nseg
223arguments describe an array of
224.Vt bus_dma_segment_t
225structures that represent the mapping.
226This array is only valid within the scope of the callback function.
227The success or failure of the mapping is indicated by the
228.Fa error
229argument.
230More information on the use of callbacks can be found in the
231description of the individual dmamap load functions.
232.It Vt bus_dmamap_callback2_t
233Client specified callback for receiving mapping information resulting from
234the load of a
235.Vt bus_dmamap_t
236via
237.Fn bus_dmamap_load_uio
238or
239.Fn bus_dmamap_load_mbuf .
240.Pp
241Callback2s are of the format:
242.Bl -tag -width indent
243.It Ft void
244.Fn "client_callback2" "void *callback_arg" "bus_dma_segment_t *segs" \
245"int nseg" "bus_size_t mapsize" "int error"
246.El
247.Pp
248Callback2's behavior is the same as
249.Vt bus_dmamap_callback_t
250with the addition that the length of the data mapped is provided via
251.Fa mapsize .
252.It Vt bus_dmasync_op_t
253Memory synchronization operation specifier.
254Bus DMA requires explicit synchronization of memory with its device
255visible mapping in order to guarantee memory coherency.
256The
257.Vt bus_dmasync_op_t
258allows the type of DMA operation that will be or has been performed
259to be communicated to the system so that the correct coherency measures
260are taken.
261The operations are represented as bitfield flags that can be combined together,
262though it only makes sense to combine PRE flags or POST flags, not both.
263See the
264.Fn bus_dmamap_sync
265description below for more details on how to use these operations.
266.Pp
267All operations specified below are performed from the host memory point of view,
268where a read implies data coming from the device to the host memory, and a write
269implies data going from the host memory to the device.
270Alternatively, the operations can be thought of in terms of driver operations,
271where reading a network packet or storage sector corresponds to a read operation
272in
273.Nm .
274.Bl -tag -width ".Dv BUS_DMASYNC_POSTWRITE"
275.It Dv BUS_DMASYNC_PREREAD
276Perform any synchronization required prior to an update of host memory by the
277device.
278.It Dv BUS_DMASYNC_PREWRITE
279Perform any synchronization required after an update of host memory by the CPU
280and prior to device access to host memory.
281.It Dv BUS_DMASYNC_POSTREAD
282Perform any synchronization required after an update of host memory by the
283device and prior to CPU access to host memory.
284.It Dv BUS_DMASYNC_POSTWRITE
285Perform any synchronization required after device access to host memory.
286.El
287.It Vt bus_dma_lock_t
288Client specified lock/mutex manipulation method.
289This will be called from
290within busdma whenever a client lock needs to be manipulated.
291In its current form, the function will be called immediately before
292the callback for a DMA load operation that has been deferred with
293.Dv BUS_DMA_LOCK
294and immediately after with
295.Dv BUS_DMA_UNLOCK .
296If the load operation does not need to be deferred, then it
297will not be called since the function loading the map should
298be holding the appropriate locks.
299This method is of the format:
300.Bl -tag -width indent
301.It Ft void
302.Fn "lockfunc" "void *lockfunc_arg" "bus_dma_lock_op_t op"
303.El
304.Pp
305The
306.Fa lockfuncarg
307argument is specified by the client during tag creation to be passed to all
308invocations of the callback.
309The
310.Fa op
311argument specifies the lock operation to perform.
312.Pp
313Two
314.Vt lockfunc
315implementations are provided for convenience.
316.Fn busdma_lock_mutex
317performs standard mutex operations on the sleep mutex provided via
318.Fa lockfuncarg .
319.Fn dflt_lock
320will generate a system panic if it is called.
321It is substituted into the tag when
322.Fa lockfunc
323is passed as
324.Dv NULL
325to
326.Fn bus_dma_tag_create
327and is useful for tags that should not be used with deferred load operations.
328.It Vt bus_dma_lock_op_t
329Operations to be performed by the client-specified
330.Fn lockfunc .
331.Bl -tag -width ".Dv BUS_DMA_UNLOCK"
332.It Dv BUS_DMA_LOCK
333Acquires and/or locks the client locking primitive.
334.It Dv BUS_DMA_UNLOCK
335Releases and/or unlocks the client locking primitive.
336.El
337.El
338.Sh FUNCTIONS
339.Bl -tag -width indent
340.It Fn bus_dma_tag_create "parent" "alignment" "boundary" "lowaddr" \
341"highaddr" "*filtfunc" "*filtfuncarg" "maxsize" "nsegments" "maxsegsz" \
342"flags" "lockfunc" "lockfuncarg" "*dmat"
343Allocates a device specific DMA tag, and initializes it according to
344the arguments provided:
345.Bl -tag -width ".Fa filtfuncarg"
346.It Fa parent
347Indicates restrictions between the parent bridge, CPU memory, and the
348device.
349Each device must use a master parent tag by calling
350.Fn bus_get_dma_tag .
351.It Fa alignment
352Alignment constraint, in bytes, of any mappings created using this tag.
353The alignment must be a power of 2.
354Hardware that can DMA starting at any address would specify
355.Em 1
356for byte alignment.
357Hardware requiring DMA transfers to start on a multiple of 4K
358would specify
359.Em 4096 .
360.It Fa boundary
361Boundary constraint, in bytes, of the target DMA memory region.
362The boundary indicates the set of addresses, all multiples of the
363boundary argument, that cannot be crossed by a single
364.Vt bus_dma_segment_t .
365The boundary must be a power of 2 and must be no smaller than the
366maximum segment size.
367.Ql 0
368indicates that there are no boundary restrictions.
369.It Fa lowaddr , highaddr
370Bounds of the window of bus address space that
371.Em cannot
372be directly accessed by the device.
373The window contains all addresses greater than
374.Fa lowaddr
375and less than or equal to
376.Fa highaddr .
377For example, a device incapable of DMA above 4GB, would specify a
378.Fa highaddr
379of
380.Dv BUS_SPACE_MAXADDR
381and a
382.Fa lowaddr
383of
384.Dv BUS_SPACE_MAXADDR_32BIT .
385Similarly a device that can only perform DMA to addresses below
38616MB would specify a
387.Fa highaddr
388of
389.Dv BUS_SPACE_MAXADDR
390and a
391.Fa lowaddr
392of
393.Dv BUS_SPACE_MAXADDR_24BIT .
394Some implementations requires that some region of device visible
395address space, overlapping available host memory, be outside the
396window.
397This area of
398.Ql safe memory
399is used to bounce requests that would otherwise conflict with
400the exclusion window.
401.It Fa filtfunc
402Optional filter function (may be
403.Dv NULL )
404to be called for any attempt to
405map memory into the window described by
406.Fa lowaddr
407and
408.Fa highaddr .
409A filter function is only required when the single window described
410by
411.Fa lowaddr
412and
413.Fa highaddr
414cannot adequately describe the constraints of the device.
415The filter function will be called for every machine page
416that overlaps the exclusion window.
417.It Fa filtfuncarg
418Argument passed to all calls to the filter function for this tag.
419May be
420.Dv NULL .
421.It Fa maxsize
422Maximum size, in bytes, of the sum of all segment lengths in a given
423DMA mapping associated with this tag.
424.It Fa nsegments
425Number of discontinuities (scatter/gather segments) allowed
426in a DMA mapped region.
427If there is no restriction,
428.Dv BUS_SPACE_UNRESTRICTED
429may be specified.
430.It Fa maxsegsz
431Maximum size, in bytes, of a segment in any DMA mapped region associated
432with
433.Fa dmat .
434.It Fa flags
435Are as follows:
436.Bl -tag -width ".Dv BUS_DMA_ALLOCNOW"
437.It Dv BUS_DMA_ALLOCNOW
438Pre-allocate enough resources to handle at least one map load operation on
439this tag.
440If sufficient resources are not available,
441.Er ENOMEM
442is returned.
443This should not be used for tags that only describe buffers that will be
444allocated with
445.Fn bus_dmamem_alloc .
446Also, due to resource sharing with other tags, this flag does not guarantee
447that resources will be allocated or reserved exclusively for this tag.
448It should be treated only as a minor optimization.
449.It Dv BUS_DMA_COHERENT
450Indicate that the DMA engine and CPU are cache-coherent.
451Cached memory may be used to back allocations created by
452.Fn bus_dmamem_alloc .
453For
454.Fn bus_dma_tag_create ,
455the
456.Dv BUS_DMA_COHERENT
457flag is currently implemented on arm64.
458.El
459.It Fa lockfunc
460Optional lock manipulation function (may be
461.Dv NULL )
462to be called when busdma
463needs to manipulate a lock on behalf of the client.
464If
465.Dv NULL
466is specified,
467.Fn dflt_lock
468is used.
469.It Fa lockfuncarg
470Optional argument to be passed to the function specified by
471.Fa lockfunc .
472.It Fa dmat
473Pointer to a bus_dma_tag_t where the resulting DMA tag will
474be stored.
475.El
476.Pp
477Returns
478.Er ENOMEM
479if sufficient memory is not available for tag creation
480or allocating mapping resources.
481.It Fn bus_dma_tag_destroy "dmat"
482Deallocate the DMA tag
483.Fa dmat
484that was created by
485.Fn bus_dma_tag_create .
486.Pp
487Returns
488.Er EBUSY
489if any DMA maps remain associated with
490.Fa dmat
491or
492.Ql 0
493on success.
494.It Fn bus_dmamap_create "dmat" "flags" "*mapp"
495Allocates and initializes a DMA map.
496Arguments are as follows:
497.Bl -tag -width ".Fa nsegments"
498.It Fa dmat
499DMA tag.
500.It Fa flags
501Are as follows:
502.Bl -tag -width ".Dv BUS_DMA_COHERENT"
503.It Dv BUS_DMA_COHERENT
504Attempt to map the memory loaded with this map such that cache sync
505operations are as cheap as possible.
506This flag is typically set on maps when the memory loaded with these will
507be accessed by both a CPU and a DMA engine, frequently such as control data
508and as opposed to streamable data such as receive and transmit buffers.
509Use of this flag does not remove the requirement of using
510.Fn bus_dmamap_sync ,
511but it may reduce the cost of performing these operations.
512For
513.Fn bus_dmamap_create ,
514the
515.Dv BUS_DMA_COHERENT
516flag is currently implemented on sparc64.
517.El
518.It Fa mapp
519Pointer to a
520.Vt bus_dmamap_t
521where the resulting DMA map will be stored.
522.El
523.Pp
524Returns
525.Er ENOMEM
526if sufficient memory is not available for creating the
527map or allocating mapping resources.
528.It Fn bus_dmamap_destroy "dmat" "map"
529Frees all resources associated with a given DMA map.
530Arguments are as follows:
531.Bl -tag -width ".Fa dmat"
532.It Fa dmat
533DMA tag used to allocate
534.Fa map .
535.It Fa map
536The DMA map to destroy.
537.El
538.Pp
539Returns
540.Er EBUSY
541if a mapping is still active for
542.Fa map .
543.It Fn bus_dmamap_load "dmat" "map" "buf" "buflen" "*callback" \
544"callback_arg" "flags"
545Creates a mapping in device visible address space of
546.Fa buflen
547bytes of
548.Fa buf ,
549associated with the DMA map
550.Fa map .
551This call will always return immediately and will not block for any reason.
552Arguments are as follows:
553.Bl -tag -width ".Fa buflen"
554.It Fa dmat
555DMA tag used to allocate
556.Fa map .
557.It Fa map
558A DMA map without a currently active mapping.
559.It Fa buf
560A kernel virtual address pointer to a contiguous (in KVA) buffer, to be
561mapped into device visible address space.
562.It Fa buflen
563The size of the buffer.
564.It Fa callback Fa callback_arg
565The callback function, and its argument.
566This function is called once sufficient mapping resources are available for
567the DMA operation.
568If resources are temporarily unavailable, this function will be deferred until
569later, but the load operation will still return immediately to the caller.
570Thus, callers should not assume that the callback will be called before the
571load returns, and code should be structured appropriately to handle this.
572See below for specific flags and error codes that control this behavior.
573.It Fa flags
574Are as follows:
575.Bl -tag -width ".Dv BUS_DMA_NOWAIT"
576.It Dv BUS_DMA_NOWAIT
577The load should not be deferred in case of insufficient mapping resources,
578and instead should return immediately with an appropriate error.
579.It Dv BUS_DMA_NOCACHE
580The generated transactions to and from the virtual page are non-cacheable.
581For
582.Fn bus_dmamap_load ,
583the
584.Dv BUS_DMA_NOCACHE
585flag is currently implemented on sparc64.
586.El
587.El
588.Pp
589Return values to the caller are as follows:
590.Bl -tag -width ".Er EINPROGRESS"
591.It 0
592The callback has been called and completed.
593The status of the mapping has been delivered to the callback.
594.It Er EINPROGRESS
595The mapping has been deferred for lack of resources.
596The callback will be called as soon as resources are available.
597Callbacks are serviced in FIFO order.
598.Pp
599Note that subsequent load operations for the same tag that do not require
600extra resources will still succeed.
601This may result in out-of-order processing of requests.
602If the caller requires the order of requests to be preserved,
603then the caller is required to stall subsequent requests until a pending
604request's callback is invoked.
605.It Er ENOMEM
606The load request has failed due to insufficient resources, and the caller
607specifically used the
608.Dv BUS_DMA_NOWAIT
609flag.
610.It Er EINVAL
611The load request was invalid.
612The callback has been called and has been provided the same error.
613This error value may indicate that
614.Fa dmat ,
615.Fa map ,
616.Fa buf ,
617or
618.Fa callback
619were invalid, or
620.Fa buflen
621was larger than the
622.Fa maxsize
623argument used to create the dma tag
624.Fa dmat .
625.El
626.Pp
627When the callback is called, it is presented with an error value
628indicating the disposition of the mapping.
629Error may be one of the following:
630.Bl -tag -width ".Er EINPROGRESS"
631.It 0
632The mapping was successful and the
633.Fa dm_segs
634callback argument contains an array of
635.Vt bus_dma_segment_t
636elements describing the mapping.
637This array is only valid during the scope of the callback function.
638.It Er EFBIG
639A mapping could not be achieved within the segment constraints provided
640in the tag even though the requested allocation size was less than maxsize.
641.El
642.It Fn bus_dmamap_load_bio "dmat" "map" "bio" "callback" "callback_arg" "flags"
643This is a variation of
644.Fn bus_dmamap_load
645which maps buffers pointed to by
646.Fa bio
647for DMA transfers.
648.Fa bio
649may point to either a mapped or unmapped buffer.
650.It Fn bus_dmamap_load_ccb "dmat" "map" "ccb" "callback" "callback_arg" "flags"
651This is a variation of
652.Fn bus_dmamap_load
653which maps data pointed to by
654.Fa ccb
655for DMA transfers.
656The data for
657.Fa ccb
658may be any of the following types:
659.Bl -tag -width ".Er CAM_DATA_SG_PADDR"
660.It CAM_DATA_VADDR
661The data is a single KVA buffer.
662.It CAM_DATA_PADDR
663The data is a single bus address range.
664.It CAM_DATA_SG
665The data is a scatter/gather list of KVA buffers.
666.It CAM_DATA_SG_PADDR
667The data is a scatter/gather list of bus address ranges.
668.It CAM_DATA_BIO
669The data is contained in a
670.Vt struct bio
671attached to the CCB.
672.El
673.Pp
674.Fn bus_dmamap_load_ccb
675supports the following CCB XPT function codes:
676.Pp
677.Bl -item -offset indent -compact
678.It
679XPT_ATA_IO
680.It
681XPT_CONT_TARGET_IO
682.It
683XPT_SCSI_IO
684.El
685.It Fn bus_dmamap_load_mbuf "dmat" "map" "mbuf" "callback2" "callback_arg" \
686"flags"
687This is a variation of
688.Fn bus_dmamap_load
689which maps mbuf chains
690for DMA transfers.
691A
692.Vt bus_size_t
693argument is also passed to the callback routine, which
694contains the mbuf chain's packet header length.
695The
696.Dv BUS_DMA_NOWAIT
697flag is implied, thus no callback deferral will happen.
698.Pp
699Mbuf chains are assumed to be in kernel virtual address space.
700.Pp
701Beside the error values listed for
702.Fn bus_dmamap_load ,
703.Er EINVAL
704will be returned if the size of the mbuf chain exceeds the maximum limit of the
705DMA tag.
706.It Fn bus_dmamap_load_mbuf_sg "dmat" "map" "mbuf" "segs" "nsegs" "flags"
707This is just like
708.Fn bus_dmamap_load_mbuf
709except that it returns immediately without calling a callback function.
710It is provided for efficiency.
711The scatter/gather segment array
712.Va segs
713is provided by the caller and filled in directly by the function.
714The
715.Va nsegs
716argument is returned with the number of segments filled in.
717Returns the same errors as
718.Fn bus_dmamap_load_mbuf .
719.It Fn bus_dmamap_load_uio "dmat" "map" "uio" "callback2" "callback_arg" "flags"
720This is a variation of
721.Fn bus_dmamap_load
722which maps buffers pointed to by
723.Fa uio
724for DMA transfers.
725A
726.Vt bus_size_t
727argument is also passed to the callback routine, which contains the size of
728.Fa uio ,
729i.e.
730.Fa uio->uio_resid .
731The
732.Dv BUS_DMA_NOWAIT
733flag is implied, thus no callback deferral will happen.
734Returns the same errors as
735.Fn bus_dmamap_load .
736.Pp
737If
738.Fa uio->uio_segflg
739is
740.Dv UIO_USERSPACE ,
741then it is assumed that the buffer,
742.Fa uio
743is in
744.Fa "uio->uio_td->td_proc" Ns 's
745address space.
746User space memory must be in-core and wired prior to attempting a map
747load operation.
748Pages may be locked using
749.Xr vslock 9 .
750.It Fn bus_dmamap_unload "dmat" "map"
751Unloads a DMA map.
752Arguments are as follows:
753.Bl -tag -width ".Fa dmam"
754.It Fa dmat
755DMA tag used to allocate
756.Fa map .
757.It Fa map
758The DMA map that is to be unloaded.
759.El
760.Pp
761.Fn bus_dmamap_unload
762will not perform any implicit synchronization of DMA buffers.
763This must be done explicitly by a call to
764.Fn bus_dmamap_sync
765prior to unloading the map.
766.It Fn bus_dmamap_sync "dmat" "map" "op"
767Performs synchronization of a device visible mapping with the CPU visible
768memory referenced by that mapping.
769Arguments are as follows:
770.Bl -tag -width ".Fa dmat"
771.It Fa dmat
772DMA tag used to allocate
773.Fa map .
774.It Fa map
775The DMA mapping to be synchronized.
776.It Fa op
777Type of synchronization operation to perform.
778See the definition of
779.Vt bus_dmasync_op_t
780for a description of the acceptable values for
781.Fa op .
782.El
783.Pp
784The
785.Fn bus_dmamap_sync
786function
787is the method used to ensure that CPU's and device's direct
788memory access (DMA) to shared
789memory is coherent.
790For example, the CPU might be used to set up the contents of a buffer
791that is to be made available to a device.
792To ensure that the data are visible via the device's mapping of that
793memory, the buffer must be loaded and a DMA sync operation of
794.Dv BUS_DMASYNC_PREWRITE
795must be performed after the CPU has updated the buffer and before the device
796access is initiated.
797If the CPU modifies this buffer again later, another
798.Dv BUS_DMASYNC_PREWRITE
799sync operation must be performed before an additional device
800access.
801Conversely, suppose a device updates memory that is to be read by a CPU.
802In this case, the buffer must be loaded, and a DMA sync operation of
803.Dv BUS_DMASYNC_PREREAD
804must be performed before the device access is initiated.
805The CPU will only be able to see the results of this memory update
806once the DMA operation has completed and a
807.Dv BUS_DMASYNC_POSTREAD
808sync operation has been performed.
809.Pp
810If read and write operations are not preceded and followed by the
811appropriate synchronization operations, behavior is undefined.
812.It Fn bus_dmamem_alloc "dmat" "**vaddr" "flags" "*mapp"
813Allocates memory that is mapped into KVA at the address returned
814in
815.Fa vaddr
816and that is permanently loaded into the newly created
817.Vt bus_dmamap_t
818returned via
819.Fa mapp .
820Arguments are as follows:
821.Bl -tag -width ".Fa alignment"
822.It Fa dmat
823DMA tag describing the constraints of the DMA mapping.
824.It Fa vaddr
825Pointer to a pointer that will hold the returned KVA mapping of
826the allocated region.
827.It Fa flags
828Flags are defined as follows:
829.Bl -tag -width ".Dv BUS_DMA_NOWAIT"
830.It Dv BUS_DMA_WAITOK
831The routine can safely wait (sleep) for resources.
832.It Dv BUS_DMA_NOWAIT
833The routine is not allowed to wait for resources.
834If resources are not available,
835.Dv ENOMEM
836is returned.
837.It Dv BUS_DMA_COHERENT
838Attempt to map this memory in a coherent fashion.
839See
840.Fn bus_dmamap_create
841above for a description of this flag.
842For
843.Fn bus_dmamem_alloc ,
844the
845.Dv BUS_DMA_COHERENT
846flag is currently implemented on arm, arm64 and sparc64.
847.It Dv BUS_DMA_ZERO
848Causes the allocated memory to be set to all zeros.
849.It Dv BUS_DMA_NOCACHE
850The allocated memory will not be cached in the processor caches.
851All memory accesses appear on the bus and are executed
852without reordering.
853For
854.Fn bus_dmamem_alloc ,
855the
856.Dv BUS_DMA_NOCACHE
857flag is currently implemented on amd64 and i386 where it results in the
858Strong Uncacheable PAT to be set for the allocated virtual address range.
859.El
860.It Fa mapp
861Pointer to a
862.Vt bus_dmamap_t
863where the resulting DMA map will be stored.
864.El
865.Pp
866The size of memory to be allocated is
867.Fa maxsize
868as specified in the call to
869.Fn bus_dma_tag_create
870for
871.Fa dmat .
872.Pp
873The current implementation of
874.Fn bus_dmamem_alloc
875will allocate all requests as a single segment.
876.Pp
877An initial load operation is required to obtain the bus address of the allocated
878memory, and an unload operation is required before freeing the memory, as
879described below in
880.Fn bus_dmamem_free .
881Maps are automatically handled by this function and should not be explicitly
882allocated or destroyed.
883.Pp
884Although an explicit load is not required for each access to the memory
885referenced by the returned map, the synchronization requirements
886as described in the
887.Fn bus_dmamap_sync
888section still apply and should be used to achieve portability on architectures
889without coherent buses.
890.Pp
891Returns
892.Er ENOMEM
893if sufficient memory is not available for completing
894the operation.
895.It Fn bus_dmamem_free "dmat" "*vaddr" "map"
896Frees memory previously allocated by
897.Fn bus_dmamem_alloc .
898Any mappings
899will be invalidated.
900Arguments are as follows:
901.Bl -tag -width ".Fa vaddr"
902.It Fa dmat
903DMA tag.
904.It Fa vaddr
905Kernel virtual address of the memory.
906.It Fa map
907DMA map to be invalidated.
908.El
909.El
910.Sh RETURN VALUES
911Behavior is undefined if invalid arguments are passed to
912any of the above functions.
913If sufficient resources cannot be allocated for a given
914transaction,
915.Er ENOMEM
916is returned.
917All
918routines that are not of type
919.Vt void
920will return 0 on success or an error
921code on failure as discussed above.
922.Pp
923All
924.Vt void
925routines will succeed if provided with valid arguments.
926.Sh LOCKING
927Two locking protocols are used by
928.Nm .
929The first is a private global lock that is used to synchronize access to the
930bounce buffer pool on the architectures that make use of them.
931This lock is strictly a leaf lock that is only used internally to
932.Nm
933and is not exposed to clients of the API.
934.Pp
935The second protocol involves protecting various resources stored in the tag.
936Since almost all
937.Nm
938operations are done through requests from the driver that created the tag,
939the most efficient way to protect the tag resources is through the lock that
940the driver uses.
941In cases where
942.Nm
943acts on its own without being called by the driver, the lock primitive
944specified in the tag is acquired and released automatically.
945An example of this is when the
946.Fn bus_dmamap_load
947callback function is called from a deferred context instead of the driver
948context.
949This means that certain
950.Nm
951functions must always be called with the same lock held that is specified in the
952tag.
953These functions include:
954.Pp
955.Bl -item -offset indent -compact
956.It
957.Fn bus_dmamap_load
958.It
959.Fn bus_dmamap_load_bio
960.It
961.Fn bus_dmamap_load_ccb
962.It
963.Fn bus_dmamap_load_mbuf
964.It
965.Fn bus_dmamap_load_mbuf_sg
966.It
967.Fn bus_dmamap_load_uio
968.It
969.Fn bus_dmamap_unload
970.It
971.Fn bus_dmamap_sync
972.El
973.Pp
974There is one exception to this rule.
975It is common practice to call some of these functions during driver start-up
976without any locks held.
977So long as there is a guarantee of no possible concurrent use of the tag by
978different threads during this operation, it is safe to not hold a lock for
979these functions.
980.Pp
981Certain
982.Nm
983operations should not be called with the driver lock held, either because
984they are already protected by an internal lock, or because they might sleep
985due to memory or resource allocation.
986The following functions must not be
987called with any non-sleepable locks held:
988.Pp
989.Bl -item -offset indent -compact
990.It
991.Fn bus_dma_tag_create
992.It
993.Fn bus_dmamap_create
994.It
995.Fn bus_dmamem_alloc
996.El
997.Pp
998All other functions do not have a locking protocol and can thus be
999called with or without any system or driver locks held.
1000.Sh SEE ALSO
1001.Xr devclass 9 ,
1002.Xr device 9 ,
1003.Xr driver 9 ,
1004.Xr rman 9 ,
1005.Xr vslock 9
1006.Pp
1007.Rs
1008.%A "Jason R. Thorpe"
1009.%T "A Machine-Independent DMA Framework for NetBSD"
1010.%J "Proceedings of the Summer 1998 USENIX Technical Conference"
1011.%Q "USENIX Association"
1012.%D "June 1998"
1013.Re
1014.Sh HISTORY
1015The
1016.Nm
1017interface first appeared in
1018.Nx 1.3 .
1019.Pp
1020The
1021.Nm
1022API was adopted from
1023.Nx
1024for use in the CAM SCSI subsystem.
1025The alterations to the original API were aimed to remove the need for
1026a
1027.Vt bus_dma_segment_t
1028array stored in each
1029.Vt bus_dmamap_t
1030while allowing callers to queue up on scarce resources.
1031.Sh AUTHORS
1032The
1033.Nm
1034interface was designed and implemented by
1035.An Jason R. Thorpe
1036of the Numerical Aerospace Simulation Facility, NASA Ames Research Center.
1037Additional input on the
1038.Nm
1039design was provided by
1040.An -nosplit
1041.An Chris Demetriou ,
1042.An Charles Hannum ,
1043.An Ross Harvey ,
1044.An Matthew Jacob ,
1045.An Jonathan Stone ,
1046and
1047.An Matt Thomas .
1048.Pp
1049The
1050.Nm
1051interface in
1052.Fx
1053benefits from the contributions of
1054.An Justin T. Gibbs ,
1055.An Peter Wemm ,
1056.An Doug Rabson ,
1057.An Matthew N. Dodd ,
1058.An Sam Leffler ,
1059.An Maxime Henrion ,
1060.An Jake Burkholder ,
1061.An Takahashi Yoshihiro ,
1062.An Scott Long
1063and many others.
1064.Pp
1065This manual page was written by
1066.An Hiten M. Pandya
1067and
1068.An Justin T. Gibbs .
1069