Removed
Link Here
|
1 |
--- include/drm-uapi/dma-buf.h.orig 2022-10-14 14:21:26 UTC |
2 |
+++ include/drm-uapi/dma-buf.h |
3 |
@@ -0,0 +1,195 @@ |
4 |
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ |
5 |
+/* |
6 |
+ * Framework for buffer objects that can be shared across devices/subsystems. |
7 |
+ * |
8 |
+ * Copyright(C) 2015 Intel Ltd |
9 |
+ * |
10 |
+ * This program is free software; you can redistribute it and/or modify it |
11 |
+ * under the terms of the GNU General Public License version 2 as published by |
12 |
+ * the Free Software Foundation. |
13 |
+ * |
14 |
+ * This program is distributed in the hope that it will be useful, but WITHOUT |
15 |
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
16 |
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for |
17 |
+ * more details. |
18 |
+ * |
19 |
+ * You should have received a copy of the GNU General Public License along with |
20 |
+ * this program. If not, see <http://www.gnu.org/licenses/>. |
21 |
+ */ |
22 |
+ |
23 |
+#ifndef _DMA_BUF_UAPI_H_ |
24 |
+#define _DMA_BUF_UAPI_H_ |
25 |
+ |
26 |
+#ifdef __linux__ |
27 |
+#include <linux/types.h> |
28 |
+#else |
29 |
+#include <sys/types.h> |
30 |
+ |
31 |
+typedef int8_t __s8; |
32 |
+typedef uint8_t __u8; |
33 |
+typedef int16_t __s16; |
34 |
+typedef uint16_t __u16; |
35 |
+typedef int32_t __s32; |
36 |
+typedef uint32_t __u32; |
37 |
+typedef int64_t __s64; |
38 |
+typedef uint64_t __u64; |
39 |
+#endif |
40 |
+ |
41 |
+/** |
42 |
+ * struct dma_buf_sync - Synchronize with CPU access. |
43 |
+ * |
44 |
+ * When a DMA buffer is accessed from the CPU via mmap, it is not always |
45 |
+ * possible to guarantee coherency between the CPU-visible map and underlying |
46 |
+ * memory. To manage coherency, DMA_BUF_IOCTL_SYNC must be used to bracket |
47 |
+ * any CPU access to give the kernel the chance to shuffle memory around if |
48 |
+ * needed. |
49 |
+ * |
50 |
+ * Prior to accessing the map, the client must call DMA_BUF_IOCTL_SYNC |
51 |
+ * with DMA_BUF_SYNC_START and the appropriate read/write flags. Once the |
52 |
+ * access is complete, the client should call DMA_BUF_IOCTL_SYNC with |
53 |
+ * DMA_BUF_SYNC_END and the same read/write flags. |
54 |
+ * |
55 |
+ * The synchronization provided via DMA_BUF_IOCTL_SYNC only provides cache |
56 |
+ * coherency. It does not prevent other processes or devices from |
57 |
+ * accessing the memory at the same time. If synchronization with a GPU or |
58 |
+ * other device driver is required, it is the client's responsibility to |
59 |
+ * wait for buffer to be ready for reading or writing before calling this |
60 |
+ * ioctl with DMA_BUF_SYNC_START. Likewise, the client must ensure that |
61 |
+ * follow-up work is not submitted to GPU or other device driver until |
62 |
+ * after this ioctl has been called with DMA_BUF_SYNC_END? |
63 |
+ * |
64 |
+ * If the driver or API with which the client is interacting uses implicit |
65 |
+ * synchronization, waiting for prior work to complete can be done via |
66 |
+ * poll() on the DMA buffer file descriptor. If the driver or API requires |
67 |
+ * explicit synchronization, the client may have to wait on a sync_file or |
68 |
+ * other synchronization primitive outside the scope of the DMA buffer API. |
69 |
+ */ |
70 |
+struct dma_buf_sync { |
71 |
+ /** |
72 |
+ * @flags: Set of access flags |
73 |
+ * |
74 |
+ * DMA_BUF_SYNC_START: |
75 |
+ * Indicates the start of a map access session. |
76 |
+ * |
77 |
+ * DMA_BUF_SYNC_END: |
78 |
+ * Indicates the end of a map access session. |
79 |
+ * |
80 |
+ * DMA_BUF_SYNC_READ: |
81 |
+ * Indicates that the mapped DMA buffer will be read by the |
82 |
+ * client via the CPU map. |
83 |
+ * |
84 |
+ * DMA_BUF_SYNC_WRITE: |
85 |
+ * Indicates that the mapped DMA buffer will be written by the |
86 |
+ * client via the CPU map. |
87 |
+ * |
88 |
+ * DMA_BUF_SYNC_RW: |
89 |
+ * An alias for DMA_BUF_SYNC_READ | DMA_BUF_SYNC_WRITE. |
90 |
+ */ |
91 |
+ __u64 flags; |
92 |
+}; |
93 |
+ |
94 |
+#define DMA_BUF_SYNC_READ (1 << 0) |
95 |
+#define DMA_BUF_SYNC_WRITE (2 << 0) |
96 |
+#define DMA_BUF_SYNC_RW (DMA_BUF_SYNC_READ | DMA_BUF_SYNC_WRITE) |
97 |
+#define DMA_BUF_SYNC_START (0 << 2) |
98 |
+#define DMA_BUF_SYNC_END (1 << 2) |
99 |
+#define DMA_BUF_SYNC_VALID_FLAGS_MASK \ |
100 |
+ (DMA_BUF_SYNC_RW | DMA_BUF_SYNC_END) |
101 |
+ |
102 |
+#define DMA_BUF_NAME_LEN 32 |
103 |
+ |
104 |
+/** |
105 |
+ * struct dma_buf_export_sync_file - Get a sync_file from a dma-buf |
106 |
+ * |
107 |
+ * Userspace can perform a DMA_BUF_IOCTL_EXPORT_SYNC_FILE to retrieve the |
108 |
+ * current set of fences on a dma-buf file descriptor as a sync_file. CPU |
109 |
+ * waits via poll() or other driver-specific mechanisms typically wait on |
110 |
+ * whatever fences are on the dma-buf at the time the wait begins. This |
111 |
+ * is similar except that it takes a snapshot of the current fences on the |
112 |
+ * dma-buf for waiting later instead of waiting immediately. This is |
113 |
+ * useful for modern graphics APIs such as Vulkan which assume an explicit |
114 |
+ * synchronization model but still need to inter-operate with dma-buf. |
115 |
+ * |
116 |
+ * The intended usage pattern is the following: |
117 |
+ * |
118 |
+ * 1. Export a sync_file with flags corresponding to the expected GPU usage |
119 |
+ * via DMA_BUF_IOCTL_EXPORT_SYNC_FILE. |
120 |
+ * |
121 |
+ * 2. Submit rendering work which uses the dma-buf. The work should wait on |
122 |
+ * the exported sync file before rendering and produce another sync_file |
123 |
+ * when complete. |
124 |
+ * |
125 |
+ * 3. Import the rendering-complete sync_file into the dma-buf with flags |
126 |
+ * corresponding to the GPU usage via DMA_BUF_IOCTL_IMPORT_SYNC_FILE. |
127 |
+ * |
128 |
+ * Unlike doing implicit synchronization via a GPU kernel driver's exec ioctl, |
129 |
+ * the above is not a single atomic operation. If userspace wants to ensure |
130 |
+ * ordering via these fences, it is the respnosibility of userspace to use |
131 |
+ * locks or other mechanisms to ensure that no other context adds fences or |
132 |
+ * submits work between steps 1 and 3 above. |
133 |
+ */ |
134 |
+struct dma_buf_export_sync_file { |
135 |
+ /** |
136 |
+ * @flags: Read/write flags |
137 |
+ * |
138 |
+ * Must be DMA_BUF_SYNC_READ, DMA_BUF_SYNC_WRITE, or both. |
139 |
+ * |
140 |
+ * If DMA_BUF_SYNC_READ is set and DMA_BUF_SYNC_WRITE is not set, |
141 |
+ * the returned sync file waits on any writers of the dma-buf to |
142 |
+ * complete. Waiting on the returned sync file is equivalent to |
143 |
+ * poll() with POLLIN. |
144 |
+ * |
145 |
+ * If DMA_BUF_SYNC_WRITE is set, the returned sync file waits on |
146 |
+ * any users of the dma-buf (read or write) to complete. Waiting |
147 |
+ * on the returned sync file is equivalent to poll() with POLLOUT. |
148 |
+ * If both DMA_BUF_SYNC_WRITE and DMA_BUF_SYNC_READ are set, this |
149 |
+ * is equivalent to just DMA_BUF_SYNC_WRITE. |
150 |
+ */ |
151 |
+ __u32 flags; |
152 |
+ /** @fd: Returned sync file descriptor */ |
153 |
+ __s32 fd; |
154 |
+}; |
155 |
+ |
156 |
+/** |
157 |
+ * struct dma_buf_import_sync_file - Insert a sync_file into a dma-buf |
158 |
+ * |
159 |
+ * Userspace can perform a DMA_BUF_IOCTL_IMPORT_SYNC_FILE to insert a |
160 |
+ * sync_file into a dma-buf for the purposes of implicit synchronization |
161 |
+ * with other dma-buf consumers. This allows clients using explicitly |
162 |
+ * synchronized APIs such as Vulkan to inter-op with dma-buf consumers |
163 |
+ * which expect implicit synchronization such as OpenGL or most media |
164 |
+ * drivers/video. |
165 |
+ */ |
166 |
+struct dma_buf_import_sync_file { |
167 |
+ /** |
168 |
+ * @flags: Read/write flags |
169 |
+ * |
170 |
+ * Must be DMA_BUF_SYNC_READ, DMA_BUF_SYNC_WRITE, or both. |
171 |
+ * |
172 |
+ * If DMA_BUF_SYNC_READ is set and DMA_BUF_SYNC_WRITE is not set, |
173 |
+ * this inserts the sync_file as a read-only fence. Any subsequent |
174 |
+ * implicitly synchronized writes to this dma-buf will wait on this |
175 |
+ * fence but reads will not. |
176 |
+ * |
177 |
+ * If DMA_BUF_SYNC_WRITE is set, this inserts the sync_file as a |
178 |
+ * write fence. All subsequent implicitly synchronized access to |
179 |
+ * this dma-buf will wait on this fence. |
180 |
+ */ |
181 |
+ __u32 flags; |
182 |
+ /** @fd: Sync file descriptor */ |
183 |
+ __s32 fd; |
184 |
+}; |
185 |
+ |
186 |
+#define DMA_BUF_BASE 'b' |
187 |
+#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) |
188 |
+ |
189 |
+/* 32/64bitness of this uapi was botched in android, there's no difference |
190 |
+ * between them in actual uapi, they're just different numbers. |
191 |
+ */ |
192 |
+#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) |
193 |
+#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32) |
194 |
+#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64) |
195 |
+#define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file) |
196 |
+#define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file) |
197 |
+ |
198 |
+#endif |