aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/ion.h
diff options
context:
space:
mode:
authorJonathan Herman <hermanjl@cs.unc.edu>2013-01-22 10:38:37 -0500
committerJonathan Herman <hermanjl@cs.unc.edu>2013-01-22 10:38:37 -0500
commitfcc9d2e5a6c89d22b8b773a64fb4ad21ac318446 (patch)
treea57612d1888735a2ec7972891b68c1ac5ec8faea /include/linux/ion.h
parent8dea78da5cee153b8af9c07a2745f6c55057fe12 (diff)
Added missing tegra files.HEADmaster
Diffstat (limited to 'include/linux/ion.h')
-rw-r--r--include/linux/ion.h347
1 files changed, 347 insertions, 0 deletions
diff --git a/include/linux/ion.h b/include/linux/ion.h
new file mode 100644
index 00000000000..9a322437a97
--- /dev/null
+++ b/include/linux/ion.h
@@ -0,0 +1,347 @@
1/*
2 * include/linux/ion.h
3 *
4 * Copyright (C) 2011 Google, Inc.
5 *
6 * This software is licensed under the terms of the GNU General Public
7 * License version 2, as published by the Free Software Foundation, and
8 * may be copied, distributed, and modified under those terms.
9 *
10 * This program is distributed in the hope that it will be useful,
11 * but WITHOUT ANY WARRANTY; without even the implied warranty of
12 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
13 * GNU General Public License for more details.
14 *
15 */
16
17#ifndef _LINUX_ION_H
18#define _LINUX_ION_H
19
20#include <linux/types.h>
21
22struct ion_handle;
23/**
24 * enum ion_heap_types - list of all possible types of heaps
25 * @ION_HEAP_TYPE_SYSTEM: memory allocated via vmalloc
26 * @ION_HEAP_TYPE_SYSTEM_CONTIG: memory allocated via kmalloc
27 * @ION_HEAP_TYPE_CARVEOUT: memory allocated from a prereserved
28 * carveout heap, allocations are physically
29 * contiguous
30 * @ION_HEAP_END: helper for iterating over heaps
31 */
32enum ion_heap_type {
33 ION_HEAP_TYPE_SYSTEM,
34 ION_HEAP_TYPE_SYSTEM_CONTIG,
35 ION_HEAP_TYPE_CARVEOUT,
36 ION_HEAP_TYPE_IOMMU,
37 ION_HEAP_TYPE_CUSTOM, /* must be last so device specific heaps always
38 are at the end of this enum */
39 ION_NUM_HEAPS,
40};
41
42#define ION_HEAP_SYSTEM_MASK (1 << ION_HEAP_TYPE_SYSTEM)
43#define ION_HEAP_SYSTEM_CONTIG_MASK (1 << ION_HEAP_TYPE_SYSTEM_CONTIG)
44#define ION_HEAP_CARVEOUT_MASK (1 << ION_HEAP_TYPE_CARVEOUT)
45
46#ifdef __KERNEL__
47struct ion_device;
48struct ion_heap;
49struct ion_mapper;
50struct ion_client;
51struct ion_buffer;
52
53/* This should be removed some day when phys_addr_t's are fully
54 plumbed in the kernel, and all instances of ion_phys_addr_t should
55 be converted to phys_addr_t. For the time being many kernel interfaces
56 do not accept phys_addr_t's that would have to */
57#define ion_phys_addr_t unsigned long
58
59/**
60 * struct ion_platform_heap - defines a heap in the given platform
61 * @type: type of the heap from ion_heap_type enum
62 * @id: unique identifier for heap. When allocating (lower numbers
63 * will be allocated from first)
64 * @name: used for debug purposes
65 * @base: base address of heap in physical memory if applicable
66 * @size: size of the heap in bytes if applicable
67 * @priv: heap specific data
68 *
69 * Provided by the board file.
70 */
71struct ion_platform_heap {
72 enum ion_heap_type type;
73 unsigned int id;
74 const char *name;
75 ion_phys_addr_t base;
76 size_t size;
77 void *priv;
78};
79
80/**
81 * struct ion_platform_data - array of platform heaps passed from board file
82 * @nr: number of structures in the array
83 * @heaps: array of platform_heap structions
84 *
85 * Provided by the board file in the form of platform data to a platform device.
86 */
87struct ion_platform_data {
88 int nr;
89 struct ion_platform_heap heaps[];
90};
91
92/**
93 * ion_client_create() - allocate a client and returns it
94 * @dev: the global ion device
95 * @heap_mask: mask of heaps this client can allocate from
96 * @name: used for debugging
97 */
98struct ion_client *ion_client_create(struct ion_device *dev,
99 unsigned int heap_mask, const char *name);
100
101/**
102 * ion_client_destroy() - free's a client and all it's handles
103 * @client: the client
104 *
105 * Free the provided client and all it's resources including
106 * any handles it is holding.
107 */
108void ion_client_destroy(struct ion_client *client);
109
110/**
111 * ion_alloc - allocate ion memory
112 * @client: the client
113 * @len: size of the allocation
114 * @align: requested allocation alignment, lots of hardware blocks have
115 * alignment requirements of some kind
116 * @flags: mask of heaps to allocate from, if multiple bits are set
117 * heaps will be tried in order from lowest to highest order bit
118 *
119 * Allocate memory in one of the heaps provided in heap mask and return
120 * an opaque handle to it.
121 */
122struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
123 size_t align, unsigned int flags);
124
125/**
126 * ion_free - free a handle
127 * @client: the client
128 * @handle: the handle to free
129 *
130 * Free the provided handle.
131 */
132void ion_free(struct ion_client *client, struct ion_handle *handle);
133
134/**
135 * ion_phys - returns the physical address and len of a handle
136 * @client: the client
137 * @handle: the handle
138 * @addr: a pointer to put the address in
139 * @len: a pointer to put the length in
140 *
141 * This function queries the heap for a particular handle to get the
142 * handle's physical address. It't output is only correct if
143 * a heap returns physically contiguous memory -- in other cases
144 * this api should not be implemented -- ion_map_dma should be used
145 * instead. Returns -EINVAL if the handle is invalid. This has
146 * no implications on the reference counting of the handle --
147 * the returned value may not be valid if the caller is not
148 * holding a reference.
149 */
150int ion_phys(struct ion_client *client, struct ion_handle *handle,
151 ion_phys_addr_t *addr, size_t *len);
152
153/**
154 * ion_map_kernel - create mapping for the given handle
155 * @client: the client
156 * @handle: handle to map
157 *
158 * Map the given handle into the kernel and return a kernel address that
159 * can be used to access this address.
160 */
161void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle);
162
163/**
164 * ion_unmap_kernel() - destroy a kernel mapping for a handle
165 * @client: the client
166 * @handle: handle to unmap
167 */
168void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle);
169
170/**
171 * ion_map_dma - create a dma mapping for a given handle
172 * @client: the client
173 * @handle: handle to map
174 *
175 * Return an sglist describing the given handle
176 */
177struct scatterlist *ion_map_dma(struct ion_client *client,
178 struct ion_handle *handle);
179
180/**
181 * ion_unmap_dma() - destroy a dma mapping for a handle
182 * @client: the client
183 * @handle: handle to unmap
184 */
185void ion_unmap_dma(struct ion_client *client, struct ion_handle *handle);
186
187/**
188 * ion_share() - given a handle, obtain a buffer to pass to other clients
189 * @client: the client
190 * @handle: the handle to share
191 *
192 * Given a handle, return a buffer, which exists in a global name
193 * space, and can be passed to other clients. Should be passed into ion_import
194 * to obtain a new handle for this buffer.
195 *
196 * NOTE: This function does do not an extra reference. The burden is on the
197 * caller to make sure the buffer doesn't go away while it's being passed to
198 * another client. That is, ion_free should not be called on this handle until
199 * the buffer has been imported into the other client.
200 */
201struct ion_buffer *ion_share(struct ion_client *client,
202 struct ion_handle *handle);
203
204/**
205 * ion_import() - given an buffer in another client, import it
206 * @client: this blocks client
207 * @buffer: the buffer to import (as obtained from ion_share)
208 *
209 * Given a buffer, add it to the client and return the handle to use to refer
210 * to it further. This is called to share a handle from one kernel client to
211 * another.
212 */
213struct ion_handle *ion_import(struct ion_client *client,
214 struct ion_buffer *buffer);
215
216/**
217 * ion_import_fd() - given an fd obtained via ION_IOC_SHARE ioctl, import it
218 * @client: this blocks client
219 * @fd: the fd
220 *
221 * A helper function for drivers that will be recieving ion buffers shared
222 * with them from userspace. These buffers are represented by a file
223 * descriptor obtained as the return from the ION_IOC_SHARE ioctl.
224 * This function coverts that fd into the underlying buffer, and returns
225 * the handle to use to refer to it further.
226 */
227struct ion_handle *ion_import_fd(struct ion_client *client, int fd);
228#endif /* __KERNEL__ */
229
230/**
231 * DOC: Ion Userspace API
232 *
233 * create a client by opening /dev/ion
234 * most operations handled via following ioctls
235 *
236 */
237
238/**
239 * struct ion_allocation_data - metadata passed from userspace for allocations
240 * @len: size of the allocation
241 * @align: required alignment of the allocation
242 * @flags: flags passed to heap
243 * @handle: pointer that will be populated with a cookie to use to refer
244 * to this allocation
245 *
246 * Provided by userspace as an argument to the ioctl
247 */
248struct ion_allocation_data {
249 size_t len;
250 size_t align;
251 unsigned int flags;
252 struct ion_handle *handle;
253};
254
255/**
256 * struct ion_fd_data - metadata passed to/from userspace for a handle/fd pair
257 * @handle: a handle
258 * @fd: a file descriptor representing that handle
259 *
260 * For ION_IOC_SHARE or ION_IOC_MAP userspace populates the handle field with
261 * the handle returned from ion alloc, and the kernel returns the file
262 * descriptor to share or map in the fd field. For ION_IOC_IMPORT, userspace
263 * provides the file descriptor and the kernel returns the handle.
264 */
265struct ion_fd_data {
266 struct ion_handle *handle;
267 int fd;
268};
269
270/**
271 * struct ion_handle_data - a handle passed to/from the kernel
272 * @handle: a handle
273 */
274struct ion_handle_data {
275 struct ion_handle *handle;
276};
277
278/**
279 * struct ion_custom_data - metadata passed to/from userspace for a custom ioctl
280 * @cmd: the custom ioctl function to call
281 * @arg: additional data to pass to the custom ioctl, typically a user
282 * pointer to a predefined structure
283 *
284 * This works just like the regular cmd and arg fields of an ioctl.
285 */
286struct ion_custom_data {
287 unsigned int cmd;
288 unsigned long arg;
289};
290
291#define ION_IOC_MAGIC 'I'
292
293/**
294 * DOC: ION_IOC_ALLOC - allocate memory
295 *
296 * Takes an ion_allocation_data struct and returns it with the handle field
297 * populated with the opaque handle for the allocation.
298 */
299#define ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
300 struct ion_allocation_data)
301
302/**
303 * DOC: ION_IOC_FREE - free memory
304 *
305 * Takes an ion_handle_data struct and frees the handle.
306 */
307#define ION_IOC_FREE _IOWR(ION_IOC_MAGIC, 1, struct ion_handle_data)
308
309/**
310 * DOC: ION_IOC_MAP - get a file descriptor to mmap
311 *
312 * Takes an ion_fd_data struct with the handle field populated with a valid
313 * opaque handle. Returns the struct with the fd field set to a file
314 * descriptor open in the current address space. This file descriptor
315 * can then be used as an argument to mmap.
316 */
317#define ION_IOC_MAP _IOWR(ION_IOC_MAGIC, 2, struct ion_fd_data)
318
319/**
320 * DOC: ION_IOC_SHARE - creates a file descriptor to use to share an allocation
321 *
322 * Takes an ion_fd_data struct with the handle field populated with a valid
323 * opaque handle. Returns the struct with the fd field set to a file
324 * descriptor open in the current address space. This file descriptor
325 * can then be passed to another process. The corresponding opaque handle can
326 * be retrieved via ION_IOC_IMPORT.
327 */
328#define ION_IOC_SHARE _IOWR(ION_IOC_MAGIC, 4, struct ion_fd_data)
329
330/**
331 * DOC: ION_IOC_IMPORT - imports a shared file descriptor
332 *
333 * Takes an ion_fd_data struct with the fd field populated with a valid file
334 * descriptor obtained from ION_IOC_SHARE and returns the struct with the handle
335 * filed set to the corresponding opaque handle.
336 */
337#define ION_IOC_IMPORT _IOWR(ION_IOC_MAGIC, 5, int)
338
339/**
340 * DOC: ION_IOC_CUSTOM - call architecture specific ion ioctl
341 *
342 * Takes the argument of the architecture specific ioctl to call and
343 * passes appropriate userdata for that ioctl
344 */
345#define ION_IOC_CUSTOM _IOWR(ION_IOC_MAGIC, 6, struct ion_custom_data)
346
347#endif /* _LINUX_ION_H */