1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
'\" te
.\" Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH DDI_DMA_SYNC 9F "Jan 16, 2006"
.SH NAME
ddi_dma_sync \- synchronize CPU and I/O views of memory
.SH SYNOPSIS
.nf
#include <sys/ddi.h>
#include <sys/sunddi.h>
\fBint\fR \fBddi_dma_sync\fR(\fBddi_dma_handle_t\fR \fIhandle\fR, \fBoff_t\fR \fIoffset\fR,
\fBsize_t\fR \fIlength\fR, \fBuint_t\fR \fItype\fR);
.fi
.SH INTERFACE LEVEL
illumos DDI specific (illumos DDI).
.SH PARAMETERS
.ne 2
.na
\fB\fIhandle\fR\fR
.ad
.RS 10n
The \fIhandle\fR filled in by a call to \fBddi_dma_alloc_handle\fR(9F).
.RE
.sp
.ne 2
.na
\fB\fIoffset\fR\fR
.ad
.RS 10n
The offset into the object described by the \fIhandle\fR.
.RE
.sp
.ne 2
.na
\fB\fIlength\fR\fR
.ad
.RS 10n
The length, in bytes, of the area to synchronize. When \fIlength\fR is zero,
the entire range starting from \fIoffset\fR to the end of the object has the
requested operation applied to it.
.RE
.sp
.ne 2
.na
\fB\fItype\fR\fR
.ad
.RS 10n
Indicates the caller's desire about what view of the memory object to
synchronize. The possible values are \fBDDI_DMA_SYNC_FORDEV\fR,
\fBDDI_DMA_SYNC_FORCPU\fR and \fBDDI_DMA_SYNC_FORKERNEL\fR.
.RE
.SH DESCRIPTION
The \fBddi_dma_sync()\fR function is used to selectively synchronize either a
\fBDMA\fR device's or a \fBCPU\fR's view of a memory object that has \fBDMA\fR
resources allocated for I/O . This may involve operations such as flushes of
\fBCPU\fR or I/O caches, as well as other more complex operations such as
stalling until hardware write buffers have drained.
.sp
.LP
This function need only be called under certain circumstances. When resources
are allocated for \fBDMA\fR using \fBddi_dma_addr_bind_handle()\fR or
\fBddi_dma_buf_bind_handle()\fR, an implicit \fBddi_dma_sync()\fR is done. When
\fBDMA\fR resources are deallocated using \fBddi_dma_unbind_handle\fR(9F), an
implicit \fBddi_dma_sync()\fR is done. However, at any time between \fBDMA\fR
resource allocation and deallocation, if the memory object has been modified by
either the \fBDMA\fR device or a \fBCPU\fR and you wish to ensure that the
change is noticed by the party that did \fBnot\fR do the modifying, a call to
\fBddi_dma_sync()\fR is required. This is true independent of any attributes of
the memory object including, but not limited to, whether or not the memory was
allocated for consistent mode I/O (see \fBddi_dma_mem_alloc\fR(9F)) or whether
or not \fBDMA\fR resources have been allocated for consistent mode I/O (see
\fBddi_dma_addr_bind_handle\fR(9F) or \fBddi_dma_buf_bind_handle\fR(9F)).
.sp
.LP
If a consistent view of the memory object must be ensured between the time
\fBDMA\fR resources are allocated for the object and the time they are
deallocated, you \fBmust\fR call \fBddi_dma_sync()\fR to ensure that either a
\fBCPU\fR or a \fBDMA\fR device has such a consistent view.
.sp
.LP
What to set \fBtype\fR to depends on the view you are trying to ensure
consistency for. If the memory object is modified by a \fBCPU\fR, and the
object is going to be \fBread\fR by the \fBDMA\fR engine of the device, use
\fBDDI_DMA_SYNC_FORDEV\fR. This ensures that the device's \fBDMA\fR engine sees
any changes that a \fBCPU\fR has made to the memory object. If the \fBDMA\fR
engine for the device has \fBwritten\fR to the memory object, and you are going
to \fBread\fR (with a \fBCPU\fR) the object (using an extant virtual address
mapping that you have to the memory object), use \fBDDI_DMA_SYNC_FORCPU\fR.
This ensures that a \fBCPU\fR's view of the memory object includes any changes
made to the object by the device's \fBDMA\fR engine. If you are only interested
in the kernel's view (kernel-space part of the \fBCPU\fR's view) you may use
\fBDDI_DMA_SYNC_FORKERNEL\fR. This gives a hint to the system\(emthat is, if it
is more economical to synchronize the kernel's view only, then do so;
otherwise, synchronize for \fBCPU\fR.
.SH RETURN VALUES
The \fBddi_dma_sync()\fR function returns:
.sp
.ne 2
.na
\fB\fBDDI_SUCCESS\fR\fR
.ad
.RS 15n
Caches are successfully flushed.
.RE
.sp
.ne 2
.na
\fB\fBDDI_FAILURE\fR\fR
.ad
.RS 15n
The address range to be flushed is out of the address range established by
\fBddi_dma_addr_bind_handle\fR(9F) or \fBddi_dma_buf_bind_handle\fR(9F).
.RE
.SH CONTEXT
The \fBddi_dma_sync()\fR function can be called from user, interrupt, or kernel
context.
.SH SEE ALSO
.BR ddi_dma_addr_bind_handle (9F),
.BR ddi_dma_alloc_handle (9F),
.BR ddi_dma_buf_bind_handle (9F),
.BR ddi_dma_mem_alloc (9F),
.BR ddi_dma_unbind_handle (9F)
.sp
.LP
\fIWriting Device Drivers\fR
|
