1 '\" te
   2 .\" Copyright (c) 2005, Sun Microsystems, Inc., All Rights Reserved
   3 .\" 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.
   4 .\" 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.
   5 .\" 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]
   6 .TH DDI_DMA_REQ 9S "Oct 12, 2005"
   7 .SH NAME
   8 ddi_dma_req \- DMA Request structure
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 #include <sys/ddidmareq.h>
  13 .fi
  14 
  15 .SH INTERFACE LEVEL
  16 .sp
  17 .LP
  18 Solaris DDI specific (Solaris DDI). This interface is obsolete.
  19 .SH DESCRIPTION
  20 .sp
  21 .LP
  22 A \fBddi_dma_req\fR structure describes a request for \fBDMA\fR resources. A
  23 driver can use it to describe forms of allocations and ways to allocate
  24 \fBDMA\fR resources for a \fBDMA\fR request.
  25 .SH STRUCTURE MEMBERS
  26 .sp
  27 .in +2
  28 .nf
  29 ddi_dma_lim_t  *dmar_limits;       /* Caller's dma engine
  30                                       constraints */
  31 uint_t         dmar_flags;         /* Contains info for
  32                                       mapping routines */
  33 int            (*dmar_fp)(caddr_t);/* Callback function */
  34 caddr_t        dmar_arg;           /* Callback function's argument */
  35 ddi_dma_obj_t  dmar_object;        /* Descrip. of  object
  36                                       to be mapped */
  37 .fi
  38 .in -2
  39 
  40 .sp
  41 .LP
  42 For the definition of the \fBDMA\fR limits structure, which \fBdmar_limits\fR
  43 points to, see \fBddi_dma_lim_sparc\fR(9S) or \fBddi_dma_lim_x86\fR(9S).
  44 .sp
  45 .LP
  46 Valid values for \fBdmar_flags\fR are:
  47 .sp
  48 .in +2
  49 .nf
  50 DDI_DMA_WRITE         /* Direction memory --> IO */
  51 DDI_DMA_READ          /* Direction IO --> memory */
  52 DDI_DMA_RDWR          /* Both read and write */
  53 DDI_DMA_REDZONE       /* Establish MMU redzone at end of mapping */
  54 DDI_DMA_PARTIAL       /* Partial mapping is allowed */
  55 DDI_DMA_CONSISTENT    /* Byte consistent access wanted */
  56 DDI_DMA_SBUS_64BIT    /* Use 64 bit capability on SBus */
  57 .fi
  58 .in -2
  59 
  60 .sp
  61 .LP
  62 \fBDDI_DMA_WRITE\fR, \fBDDI_DMA_READ\fR, and \fBDDI_DMA_RDWR\fR describe the
  63 intended direction of the \fBDMA \fRtransfer. Some implementations might
  64 explicitly disallow \fBDDI_DMA_RDWR\fR.
  65 .sp
  66 .LP
  67 \fBDDI_DMA_REDZONE\fR asks the system to establish a protected  \fBred zone\fR
  68 after the object. The \fBDMA\fR resource allocation functions do not guarantee
  69 the success of this request, as some implementations might not have the
  70 hardware ability to support it.
  71 .sp
  72 .LP
  73 \fBDDI_DMA_PARTIAL\fR lets the system know that the caller can accept partial
  74 mapping. That is, if the size of the object exceeds the resources available,
  75 the system allocates only a portion of the object and returns status indicating
  76 this partial allocation. At a later point, the caller can use
  77 \fBddi_dma_curwin\fR(9F) and \fBddi_dma_movwin\fR(9F) to change the valid
  78 portion of the object that has resources allocated.
  79 .sp
  80 .LP
  81 \fBDDI_DMA_CONSISTENT\fR gives a hint to the system that the object should be
  82 mapped for  \fBbyte consistent\fR access. Normal data transfers usually use a
  83 \fBstreaming\fR mode of operation. They start at a specific point, transfer a
  84 fairly large amount of data sequentially, and then stop, usually on an aligned
  85 boundary. Control mode data transfers for memory-resident device control blocks
  86 (for example, Ethernet message descriptors) do not access memory in such a
  87 sequential fashion. Instead, they tend to modify a few words or bytes, move
  88 around and maybe modify a few more.
  89 .sp
  90 .LP
  91 Many machine implementations make this non-sequential memory access difficult
  92 to control in a generic and seamless fashion. Therefore, explicit
  93 synchronization steps using \fBddi_dma_sync\fR(9F) or \fBddi_dma_free\fR(9F)
  94 are required to make the view of a memory object shared between a \fBCPU \fRand
  95 a \fBDMA\fR device consistent. However, proper use of the
  96 \fBDDI_DMA_CONSISTENT\fR flag can create a condition in which a system will
  97 pick resources in a way that makes these synchronization steps are as efficient
  98 as possible.
  99 .sp
 100 .LP
 101 \fBDDI_DMA_SBUS_64BIT\fR tells the system that the device can perform 64-bit
 102 transfers on a 64-bit SBus. If the SBus does not support 64-bit data transfers,
 103 data will be transferred in 32-bit mode.
 104 .sp
 105 .LP
 106 The callback function specified by the member \fBdmar_fp\fR indicates how a
 107 caller to one of the \fBDMA\fR resource allocation functions wants to deal with
 108 the possibility of resources not being available. (See
 109 \fBddi_dma_setup\fR(9F).) If \fBdmar_fp\fR is set to \fBDDI_DMA_DONTWAIT\fR,
 110 then the caller does not care if the allocation fails, and can deal with an
 111 allocation failure appropriately. Setting \fBdmar_fp\fR to \fBDDI_DMA_SLEEP\fR
 112 indicates the caller wants to have the allocation routines wait for resources
 113 to become available. If any other value is set, and a \fBDMA\fR resource
 114 allocation fails, this value is assumed to be a function to call later, when
 115 resources become available. When the specified function is called, it is passed
 116 the value set in the structure member \fBdmar_arg\fR. The specified callback
 117 function \fBmust\fR return either:
 118 .sp
 119 .ne 2
 120 .na
 121 \fB\fB0\fR\fR
 122 .ad
 123 .RS 5n
 124 Indicating that it attempted to allocate a \fBDMA\fR resource but failed to do
 125 so, again, in which case the callback function will be put back on a list to be
 126 called again later.
 127 .RE
 128 
 129 .sp
 130 .ne 2
 131 .na
 132 \fB\fB1\fR\fR
 133 .ad
 134 .RS 5n
 135 Indicating either success at allocating \fBDMA\fR resources or that it no
 136 longer wants to retry.
 137 .RE
 138 
 139 .sp
 140 .LP
 141 The callback function is called in interrupt context. Therefore, only system
 142 functions and contexts that are accessible from interrupt context are
 143 available. The callback function must take whatever steps necessary to protect
 144 its critical resources, data structures, and queues.
 145 .sp
 146 .LP
 147 It is possible that a call to \fBddi_dma_free\fR(9F), which frees \fBDMA\fR
 148 resources, might cause a callback function to be called and, unless some care
 149 is taken, an undesired recursion can occur. This can cause an undesired
 150 recursive \fBmutex_enter\fR(9F), which makes the system panic.
 151 .SS "dmar_object Structure"
 152 .sp
 153 .LP
 154 The \fBdmar_object\fR member of the \fBddi_dma_req\fR structure is itself a
 155 complex and extensible structure:
 156 .sp
 157 .in +2
 158 .nf
 159 uint_t            dmao_size;     /* size, in bytes, of the object */
 160 ddi_dma_atyp_t    dmao_type;     /* type of object */
 161 ddi_dma_aobj_t    dmao_obj;      /* the object described */
 162 .fi
 163 .in -2
 164 
 165 .sp
 166 .LP
 167 The  \fBdmao_size\fR element is the size, in bytes, of the object resources
 168 allocated for \fBDMA\fR.
 169 .sp
 170 .LP
 171 The \fBdmao_type\fR element selects the kind of object described by
 172 \fBdmao_obj\fR. It can be set to \fBDMA_OTYP_VADDR\fR, indicating virtual
 173 addresses.
 174 .sp
 175 .LP
 176 The last element, \fBdmao_obj\fR, consists of the virtual address type:
 177 .sp
 178 .in +2
 179 .nf
 180 struct v_address virt_obj;
 181 .fi
 182 .in -2
 183 
 184 .sp
 185 .LP
 186 It is specified as:
 187 .sp
 188 .in +2
 189 .nf
 190 struct v_address {
 191       caddr_t      v_addr;   /* base virtual address */
 192       struct as    *v_as;    /* pointer to address space */
 193       void         *v_priv;  /* priv data for shadow I/O */
 194 };
 195 .fi
 196 .in -2
 197 
 198 .SH ATTRIBUTES
 199 .sp
 200 .LP
 201 See \fBattributes\fR(5) for descriptions of the following attributes:
 202 .sp
 203 
 204 .sp
 205 .TS
 206 box;
 207 c | c
 208 l | l .
 209 ATTRIBUTE TYPE  ATTRIBUTE VALUE
 210 _
 211 Interface Stability     Obsolete
 212 .TE
 213 
 214 .SH SEE ALSO
 215 .sp
 216 .LP
 217 \fBddi_dma_addr_setup\fR(9F), \fBddi_dma_buf_setup\fR(9F),
 218 \fBddi_dma_curwin\fR(9F), \fBddi_dma_free\fR(9F), \fBddi_dma_movwin\fR(9F),
 219 \fBddi_dma_setup\fR(9F), \fBddi_dma_sync\fR(9F), \fBmutex\fR(9F)
 220 .sp
 221 .LP
 222 \fIWriting Device Drivers\fR