| blob | 5f53976f14ac61423eac04e4e9307653cd950ca3 |
1 .\" $NetBSD$
2 .\"
3 .\" Copyright (c) 1998 Jason R. Thorpe.
4 .\" All rights reserved.
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\" notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\" notice, this list of conditions and the following disclaimer in the
13 .\" documentation and/or other materials provided with the distribution.
14 .\" 3. All advertising materials mentioning features or use of this software
15 .\" must display the following acknowledgements:
16 .\" This product includes software developed for the NetBSD Project
17 .\" by Jason R. Thorpe.
18 .\" 4. The name of the author may not be used to endorse or promote products
19 .\" derived from this software without specific prior written permission.
20 .\"
21 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
22 .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
23 .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
24 .\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
25 .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
26 .\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
27 .\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
28 .\" AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
29 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
30 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
31 .\" SUCH DAMAGE.
32 .\"
33 .sh 1 "Design considerations"
34 .pp
35 Hiding host and bus details is actually very straightforward.
36 Handling WYSIWYG and direct-mapped DMA
37 mechanisms is trivial. Handling scatter-gather-mapped DMA
38 is also very easy, with the help of state kept in machine-dependent
39 code layers. The presence and semantics of caches are also
40 easy to handle with a set of four "synchronization" operations,
41 and once caches are handled, DMA bouncing is conceptually trivial
42 if viewed as a non-DMA-coherent cache.
43 Unfortunately, while these operations are quite easy to do individually,
44 traditional kernels do not provide a sufficiently abstract interface to
45 the operations. This means that device drivers in these traditional
46 kernels must handle each case explicitly.
47 .pp
48 In addition to the interface to
49 these operations, a comprehensive DMA framework must also consider data
50 buffer structures and DMA-safe memory handling.
51 .sh 2 "Data buffer structures"
52 .pp
53 The BSD kernel has essentially three different
54 structures used to represent data buffers. The first is a simple linear
55 buffer in virtual space, for example the data areas used to implement the
56 file system buffer cache, and miscellaneous buffers allocated by the general
57 purpose kernel memory allocator. The second is the \fImbuf chain\fR. Mbufs
58 are typically used by code which implements inter-process communication
59 and networking. Their structure, small buffers chained together, reduces
60 memory fragmentation and allows packet headers to be prepended easily. The
61 third is the \fIuio\fR structure. This structure describes software
62 scatter-gather to the kernel address space or to the address space of a
63 specific process. It is most commonly used by the \fIread(2)\fR and
64 \fIwrite(2)\fR system calls.
65 While it would be possible for the device driver to treat the two more
66 complex buffer structures as sets of multiple simple linear buffers,
67 this is undesirable in terms of source code maintenance; the code to
68 handle these data buffer structures can be complex, especially
69 in terms of error handling.
70 .pp
71 In addition to the obvious need to DMA to and from memory mapped into
72 kernel address space, it is common in modern operating systems to
73 implement an optimized I/O interface for user processes which provides
74 a method for devices to DMA directly to or from memory regions mapped into
75 a process's address space. While this facility is partially provided for
76 character device I/O by double-mapping the user buffer into kernel address
77 space, the interface is not sufficiently general, and consumes kernel
78 resources. This is somewhat related to the \fIuio\fR structure, in that
79 the \fIuio\fR is capable of addressing buffers in a process's address space.
80 However it may be desirable to use an alternate data format, such as a
81 linear buffer, in some applications. In order to implement this, the DMA
82 mapping framework must have access to processes' virtual memory structures.
83 .pp
84 It may also be desirable to DMA to or from buffers not mapped into
85 any address space. The obvious example is frame grabbers. These
86 devices, which capture video images, often require large, physically
87 contiguous memory regions to store the captured image data. On some
88 architectures, mapping of virtual address space is expensive. An
89 application may wish to give a large buffer to the device, allow the
90 device to continuously update the buffer, and then only map small regions
91 of the buffer at any given time. Since the entire buffer need not be
92 mapped into virtual address space, the DMA framework should provide an
93 interface for using raw, unmapped buffers in DMA transfers.
94 .sh 2 "DMA-safe memory handling"
95 .pp
96 A comprehensive DMA framework must also provide several memory
97 handling facilities. The most obvious of these is a method of
98 allocating (and freeing) DMA-safe memory. The term "DMA-safe" is
99 a way of describing a set of attributes the memory will have.
100 First, DMA-safe memory must be addressable within the
101 constraints of the bus. It must also be allocated in such a
102 way as to not exceed the number of physical segments\** specified
103 by the caller.
104 .(f
105 \**This is somewhat misleading. The actual constraint is on
106 the number of DMA segments the memory may map to. However, this
107 usually corresponds directly to the number of physical memory
108 segments which make up the allocated memory.
109 .)f
110 .pp
111 In order for the kernel to access the DMA-safe memory, a method
112 must exist to map this memory into kernel virtual address space.
113 This is a fairly straightforward operation, with one exception.
114 On some platforms which do not have cache-coherent DMA, cache
115 flushes are very expensive. However, it is sometimes possible to
116 mark virtual mappings of memory as cache-inhibited, or access
117 physical memory though a cache-inhibited direct-mapped address
118 segment. In order to accommodate these situations, a hint may be
119 provided to the memory mapping function which specifies that the
120 user of this memory wishes to avoid expensive data cache flushes.
121 .pp
122 To facilitate optimized I/O to process address spaces, it is necessary
123 to provide processes a way of mapping a DMA-safe memory area.
124 The most convenient way to do this is via a device driver's \fImmap()\fR
125 entry point. Thus, a DMA mapping framework must have a way to
126 communicate with the VM system's \fIdevice pager\**\fR.
127 .(f
128 \**The \fIdevice pager\fR provides support for memory mapping
129 devices into a process's address space.
130 .)f
131 .pp
132 All of these requirements must be considered in the design of a
133 complete DMA framework. When possible, the framework may
134 merge semantically similar operations or concepts, but it must
135 address all of these issues. The next section describes the
136 interface provided by such a framework.