2 .\" Copyright 1989 AT&T
3 .\" Copyright (c) 2002, Sun Microsystems, Inc. All Rights Reserved
4 .\" 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.
5 .\" 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.
6 .\" 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]
7 .TH MMAP 9E "Sep 27, 2002"
9 mmap \- check virtual mapping for memory mapped device
13 #include <sys/types.h>
20 \fBint prefix\fR\fBmmap\fR(\fBdev_t\fR \fIdev\fR, \fBoff_t\fR \fIoff\fR, \fBint\fR \fIprot\fR);
26 This interface is obsolete. \fBdevmap\fR(9E) should be used instead.
34 Device whose memory is to be mapped.
43 Offset within device memory at which mapping begins.
52 A bit field that specifies the protections this page of memory will receive.
53 Possible settings are:
57 \fB\fBPROT_READ\fR \fR
60 Read access will be granted.
66 \fB\fBPROT_WRITE\fR \fR
69 Write access will be granted.
75 \fB\fBPROT_EXEC\fR \fR
78 Execute access will be granted.
84 \fB\fBPROT_USER\fR \fR
87 User-level access will be granted.
96 All access will be granted.
104 Future releases of Solaris will provide this function for binary and source
105 compatibility. However, for increased functionality, use \fBdevmap\fR(9E)
106 instead. See \fBdevmap\fR(9E) for details.
109 The \fBmmap()\fR entry point is a required entry point for character drivers
110 supporting memory-mapped devices. A memory mapped device has memory that can be
111 mapped into a process's address space. The \fBmmap\fR(2) system call, when
112 applied to a character special file, allows this device memory to be mapped
113 into user space for direct access by the user application.
116 The \fBmmap()\fR entry point is called as a result of an \fBmmap\fR(2) system
117 call, and also as a result of a page fault. \fBmmap()\fR is called to translate
118 the offset \fIoff\fR in device memory to the corresponding physical page frame
122 The \fBmmap()\fR entry point checks if the offset \fIoff\fR is within the range
123 of pages exported by the device. For example, a device that has 512 bytes of
124 memory that can be mapped into user space should not support offsets greater
125 than 512. If the offset does not exist, then \fB-1\fR is returned. If the
126 offset does exist, \fBmmap()\fR returns the value returned by
127 \fBhat_getkpfnum\fR(9F) for the physical page in device memory containing the
131 \fBhat_getkpfnum\fR(9F) accepts a kernel virtual address as an argument. A
132 kernel virtual address can be obtained by calling \fBddi_regs_map_setup\fR(9F)
133 in the driver's \fBattach\fR(9E) routine. The corresponding
134 \fBddi_regs_map_free\fR(9F) call can be made in the driver's \fBdetach\fR(9E)
135 routine. Refer to the example below \fImmap Entry Point\fR for more
139 \fBmmap()\fR should only be supported for memory-mapped devices. See
140 \fBsegmap\fR(9E) for further information on memory-mapped device drivers.
143 If a device driver shares data structures with the application, for example
144 through exported kernel memory, and the driver gets recompiled for a 64-bit
145 kernel but the application remains 32-bit, the binary layout of any data
146 structures will be incompatible if they contain longs or pointers. The driver
147 needs to know whether there is a model mismatch between the current thread and
148 the kernel and take necessary action. \fBddi_mmap_get_model\fR(9F) can be use
149 to get the C Language Type Model which the current thread expects. In
150 combination with \fBddi_model_convert_from\fR(9F) the driver can determine
151 whether there is a data model mismatch between the current thread and the
152 device driver. The device driver might have to adjust the shape of data
153 structures before exporting them to a user thread which supports a different
154 data model. See \fBddi_mmap_get_model\fR(9F) for an example.
158 If the protection and offset are valid for the device, the driver should return
159 the value returned by \fBhat_getkpfnum\fR(9F), for the page at offset \fIoff\fR
160 in the device's memory. If not, \fB-1\fR should be returned.
163 \fBExample 1 \fR\fBmmap()\fR Entry Point
166 The following is an example of the \fBmmap()\fR entry point. If offset
167 \fIoff\fR is valid, \fBhat_getkpfnum\fR(9F) is called to obtain the page frame
168 number corresponding to this offset in the device's memory. In this example,
169 \fBxsp\(->regp\(->csr\fR is a kernel virtual address which maps to device
170 memory. \fBddi_regs_map_setup\fR(9F) can be used to obtain this address. For
171 example, \fBddi_regs_map_setup\fR(9F) can be called in the driver's
172 \fBattach\fR(9E) routine. The resulting kernel virtual address is stored in the
173 \fBxxstate\fR structure, which is accessible from the driver's \fBmmap()\fR
174 entry point. See \fBddi_soft_state\fR(9F). The corresponding
175 \fBddi_regs_map_free\fR(9F) call can be made in the driver's \fBdetach\fR(9E)
195 xxmmap(dev_t dev, off_t off, int prot)
200 /* No write access */
201 if (prot & PROT_WRITE)
204 instance = getminor(dev);
205 xsp = ddi_get_soft_state(statep, instance);
209 /* check for a valid offset */
210 if ( off is invalid )
212 return (hat_getkpfnum (xsp->regp->csr + off));
220 See \fBattributes\fR(5) for a description of the following attributes:
228 ATTRIBUTE TYPE ATTRIBUTE VALUE
230 Stability Level Obsolete
236 \fBmmap\fR(2), \fBattributes\fR(5), \fBattach\fR(9E), \fBdetach\fR(9E),
237 \fBdevmap\fR(9E), \fBsegmap\fR(9E), \fBddi_btop\fR(9F),
238 \fBddi_get_soft_state\fR(9F), \fBddi_mmap_get_model\fR(9F),
239 \fBddi_model_convert_from\fR(9F), \fBddi_regs_map_free\fR(9F),
240 \fBddi_regs_map_setup\fR(9F), \fBddi_soft_state\fR(9F), \fBdevmap_setup\fR(9F),
241 \fBgetminor\fR(9F), \fBhat_getkpfnum\fR(9F)
244 \fIWriting Device Drivers\fR
248 For some devices, mapping device memory in the driver's \fBattach\fR(9E)
249 routine and unmapping device memory in the driver's \fBdetach\fR(9E) routine is
250 a sizeable drain on system resources. This is especially true for devices with
251 a large amount of physical address space.
254 One alternative is to create a mapping for only the first page of device memory
255 in \fBattach\fR(9E). If the device memory is contiguous, a kernel page frame
256 number may be obtained by calling \fBhat_getkpfnum\fR(9F) with the kernel
257 virtual address of the first page of device memory and adding the desired page
258 offset to the result. The page offset may be obtained by converting the byte
259 offset \fIoff\fR to pages. See \fBddi_btop\fR(9F).
262 Another alternative is to call \fBddi_regs_map_setup\fR(9F) and
263 \fBddi_regs_map_free\fR(9F) in \fBmmap()\fR. These function calls would bracket
264 the call to \fBhat_getkpfnum\fR(9F).
267 However, note that the above alternatives may not work in all cases. The
268 existence of intermediate nexus devices with memory management unit translation
269 resources that are not locked down may cause unexpected and undefined behavior.