forked from ~ljy/RK356X_SDK_RELEASE

blame | history | patch | commit | commitdiff
hc
2024-05-10 37f49e37ab4cb5d0bc4c60eb5c6d4dd57db767bb 
 kernel/include/uapi/drm/drm_fourcc.h
....@@ -30,10 +30,49 @@
3030 extern "C" {
3131 #endif
3232 
33
+/**
34
+ * DOC: overview
35
+ *
36
+ * In the DRM subsystem, framebuffer pixel formats are described using the
37
+ * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the
38
+ * fourcc code, a Format Modifier may optionally be provided, in order to
39
+ * further describe the buffer's format - for example tiling or compression.
40
+ *
41
+ * Format Modifiers
42
+ * ----------------
43
+ *
44
+ * Format modifiers are used in conjunction with a fourcc code, forming a
45
+ * unique fourcc:modifier pair. This format:modifier pair must fully define the
46
+ * format and data layout of the buffer, and should be the only way to describe
47
+ * that particular buffer.
48
+ *
49
+ * Having multiple fourcc:modifier pairs which describe the same layout should
50
+ * be avoided, as such aliases run the risk of different drivers exposing
51
+ * different names for the same data format, forcing userspace to understand
52
+ * that they are aliases.
53
+ *
54
+ * Format modifiers may change any property of the buffer, including the number
55
+ * of planes and/or the required allocation size. Format modifiers are
56
+ * vendor-namespaced, and as such the relationship between a fourcc code and a
57
+ * modifier is specific to the modifer being used. For example, some modifiers
58
+ * may preserve meaning - such as number of planes - from the fourcc code,
59
+ * whereas others may not.
60
+ *
61
+ * Vendors should document their modifier usage in as much detail as
62
+ * possible, to ensure maximum compatibility across devices, drivers and
63
+ * applications.
64
+ *
65
+ * The authoritative list of format modifier codes is found in
66
+ * `include/uapi/drm/drm_fourcc.h`
67
+ */
68
+
3369 #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
3470 				 ((__u32)(c) << 16) | ((__u32)(d) << 24))
3571 
36
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of little endian */
72
+#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of little endian */
73
+
74
+/* Reserve 0 for the invalid format specifier */
75
+#define DRM_FORMAT_INVALID	0
3776 
3877 /* color index */
3978 #define DRM_FORMAT_C8		fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
....@@ -105,6 +144,17 @@
105144 #define DRM_FORMAT_RGBA1010102	fourcc_code('R', 'A', '3', '0') /* [31:0] R:G:B:A 10:10:10:2 little endian */
106145 #define DRM_FORMAT_BGRA1010102	fourcc_code('B', 'A', '3', '0') /* [31:0] B:G:R:A 10:10:10:2 little endian */
107146 
147
+/*
148
+ * Floating point 64bpp RGB
149
+ * IEEE 754-2008 binary16 half-precision float
150
+ * [15:0] sign:exponent:mantissa 1:5:10
151
+ */
152
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0] x:R:G:B 16:16:16:16 little endian */
153
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0] x:B:G:R 16:16:16:16 little endian */
154
+
155
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] A:R:G:B 16:16:16:16 little endian */
156
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] A:B:G:R 16:16:16:16 little endian */
157
+
108158 /* packed YCbCr */
109159 #define DRM_FORMAT_YUYV		fourcc_code('Y', 'U', 'Y', 'V') /* [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
110160 #define DRM_FORMAT_YVYU		fourcc_code('Y', 'V', 'Y', 'U') /* [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
....@@ -112,6 +162,52 @@
112162 #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
113163 
114164 #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
165
+#define DRM_FORMAT_XYUV8888	fourcc_code('X', 'Y', 'U', 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
166
+#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0] Cr:Cb:Y 8:8:8 little endian */
167
+#define DRM_FORMAT_VUY101010	fourcc_code('V', 'U', '3', '0') /* Y followed by U then V, 10:10:10. Non-linear modifier only */
168
+
169
+/*
170
+ * packed Y2xx indicate for each component, xx valid data occupy msb
171
+ * 16-xx padding occupy lsb
172
+ */
173
+#define DRM_FORMAT_Y210         fourcc_code('Y', '2', '1', '0') /* [63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
174
+#define DRM_FORMAT_Y212         fourcc_code('Y', '2', '1', '2') /* [63:0] Cr0:0:Y1:0:Cb0:0:Y0:0 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
175
+#define DRM_FORMAT_Y216         fourcc_code('Y', '2', '1', '6') /* [63:0] Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels */
176
+
177
+/*
178
+ * packed Y4xx indicate for each component, xx valid data occupy msb
179
+ * 16-xx padding occupy lsb except Y410
180
+ */
181
+#define DRM_FORMAT_Y410         fourcc_code('Y', '4', '1', '0') /* [31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
182
+#define DRM_FORMAT_Y412         fourcc_code('Y', '4', '1', '2') /* [63:0] A:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian */
183
+#define DRM_FORMAT_Y416         fourcc_code('Y', '4', '1', '6') /* [63:0] A:Cr:Y:Cb 16:16:16:16 little endian */
184
+
185
+#define DRM_FORMAT_XVYU2101010	fourcc_code('X', 'V', '3', '0') /* [31:0] X:Cr:Y:Cb 2:10:10:10 little endian */
186
+#define DRM_FORMAT_XVYU12_16161616	fourcc_code('X', 'V', '3', '6') /* [63:0] X:0:Cr:0:Y:0:Cb:0 12:4:12:4:12:4:12:4 little endian */
187
+#define DRM_FORMAT_XVYU16161616	fourcc_code('X', 'V', '4', '8') /* [63:0] X:Cr:Y:Cb 16:16:16:16 little endian */
188
+
189
+/*
190
+ * packed YCbCr420 2x2 tiled formats
191
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
192
+ */
193
+/* [63:0]   A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0  1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
194
+#define DRM_FORMAT_Y0L0		fourcc_code('Y', '0', 'L', '0')
195
+/* [63:0]   X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0  1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
196
+#define DRM_FORMAT_X0L0		fourcc_code('X', '0', 'L', '0')
197
+
198
+/* [63:0]   A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0  1:1:10:10:10:1:1:10:10:10 little endian */
199
+#define DRM_FORMAT_Y0L2		fourcc_code('Y', '0', 'L', '2')
200
+/* [63:0]   X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0  1:1:10:10:10:1:1:10:10:10 little endian */
201
+#define DRM_FORMAT_X0L2		fourcc_code('X', '0', 'L', '2')
202
+
203
+/*
204
+ * 1-plane YUV 4:2:0
205
+ * In these formats, the component ordering is specified (Y, followed by U
206
+ * then V), but the exact Linear layout is undefined.
207
+ * These formats can only be used with a non-Linear modifier.
208
+ */
209
+#define DRM_FORMAT_YUV420_8BIT	fourcc_code('Y', 'U', '0', '8')
210
+#define DRM_FORMAT_YUV420_10BIT	fourcc_code('Y', 'U', '1', '0')
115211 
116212 /*
117213  * 2 plane RGB + A
....@@ -140,21 +236,65 @@
140236 #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
141237 #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
142238 #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
239
+/*
240
+ * 2 plane YCbCr
241
+ * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
242
+ * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
243
+ */
244
+#define DRM_FORMAT_NV15		fourcc_code('N', 'V', '1', '5') /* 2x2 subsampled Cr:Cb plane */
245
+#define DRM_FORMAT_NV20		fourcc_code('N', 'V', '2', '0') /* 2x1 subsampled Cr:Cb plane */
246
+#define DRM_FORMAT_NV30		fourcc_code('N', 'V', '3', '0') /* non-subsampled Cr:Cb plane */
143247 
144248 /*
145
- * 2 plane YCbCr 10bit
146
- * index 0 = Y plane, [9:0] Y
147
- * index 1 = Cr:Cb plane, [19:0] Cr:Cb little endian
148
- * or
149
- * index 1 = Cb:Cr plane, [19:0] Cb:Cr little endian
249
+ * 2 plane YCbCr MSB aligned
250
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
251
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
150252  */
253
+#define DRM_FORMAT_P210		fourcc_code('P', '2', '1', '0') /* 2x1 subsampled Cr:Cb plane, 10 bit per channel */
151254 
152
-#define DRM_FORMAT_NV12_10	fourcc_code('N', 'A', '1', '2') /* 2x2 subsampled Cr:Cb plane */
153
-#define DRM_FORMAT_NV21_10	fourcc_code('N', 'A', '2', '1') /* 2x2 subsampled Cb:Cr plane */
154
-#define DRM_FORMAT_NV16_10	fourcc_code('N', 'A', '1', '6') /* 2x1 subsampled Cr:Cb plane */
155
-#define DRM_FORMAT_NV61_10	fourcc_code('N', 'A', '6', '1') /* 2x1 subsampled Cb:Cr plane */
156
-#define DRM_FORMAT_NV24_10	fourcc_code('N', 'A', '2', '4') /* non-subsampled Cr:Cb plane */
157
-#define DRM_FORMAT_NV42_10	fourcc_code('N', 'A', '4', '2') /* non-subsampled Cb:Cr plane */
255
+/*
256
+ * 2 plane YCbCr MSB aligned
257
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
258
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
259
+ */
260
+#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
261
+
262
+/*
263
+ * 2 plane YCbCr MSB aligned
264
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
265
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
266
+ */
267
+#define DRM_FORMAT_P012		fourcc_code('P', '0', '1', '2') /* 2x2 subsampled Cr:Cb plane 12 bits per channel */
268
+
269
+/*
270
+ * 2 plane YCbCr MSB aligned
271
+ * index 0 = Y plane, [15:0] Y little endian
272
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
273
+ */
274
+#define DRM_FORMAT_P016		fourcc_code('P', '0', '1', '6') /* 2x2 subsampled Cr:Cb plane 16 bits per channel */
275
+
276
+/* 2 plane YCbCr420.
277
+ * 3 10 bit components and 2 padding bits packed into 4 bytes.
278
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
279
+ * index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0 [2:10:10:10:2:10:10:10] little endian
280
+ */
281
+#define DRM_FORMAT_P030		fourcc_code('P', '0', '3', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel packed */
282
+
283
+/* 3 plane non-subsampled (444) YCbCr
284
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
285
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
286
+ * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
287
+ * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
288
+ */
289
+#define DRM_FORMAT_Q410		fourcc_code('Q', '4', '1', '0')
290
+
291
+/* 3 plane non-subsampled (444) YCrCb
292
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
293
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
294
+ * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
295
+ * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
296
+ */
297
+#define DRM_FORMAT_Q401		fourcc_code('Q', '4', '0', '1')
158298 
159299 /*
160300  * 3 plane YCbCr
....@@ -199,7 +339,10 @@
199339 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
200340 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
201341 #define DRM_FORMAT_MOD_VENDOR_ARM     0x08
342
+#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
343
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
202344 #define DRM_FORMAT_MOD_VENDOR_ROCKCHIP 0x0b
345
+
203346 /* add more to the end as needed */
204347 
205348 #define DRM_FORMAT_RESERVED	      ((1ULL << 56) - 1)
....@@ -213,7 +356,32 @@
213356  * When adding a new token please document the layout with a code comment,
214357  * similar to the fourcc codes above. drm_fourcc.h is considered the
215358  * authoritative source for all of these.
359
+ *
360
+ * Generic modifier names:
361
+ *
362
+ * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names
363
+ * for layouts which are common across multiple vendors. To preserve
364
+ * compatibility, in cases where a vendor-specific definition already exists and
365
+ * a generic name for it is desired, the common name is a purely symbolic alias
366
+ * and must use the same numerical value as the original definition.
367
+ *
368
+ * Note that generic names should only be used for modifiers which describe
369
+ * generic layouts (such as pixel re-ordering), which may have
370
+ * independently-developed support across multiple vendors.
371
+ *
372
+ * In future cases where a generic layout is identified before merging with a
373
+ * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
374
+ * 'NONE' could be considered. This should only be for obvious, exceptional
375
+ * cases to avoid polluting the 'GENERIC' namespace with modifiers which only
376
+ * apply to a single vendor.
377
+ *
378
+ * Generic names should not be used for cases where multiple hardware vendors
379
+ * have implementations of the same standardised compression scheme (such as
380
+ * AFBC). In those cases, all implementations should use the same format
381
+ * modifier(s), reflecting the vendor of the standard.
216382  */
383
+
384
+#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
217385 
218386 /*
219387  * Invalid Modifier
....@@ -244,9 +412,12 @@
244412  * a platform-dependent stride. On top of that the memory can apply
245413  * platform-depending swizzling of some higher address bits into bit6.
246414  *
247
- * This format is highly platforms specific and not useful for cross-driver
248
- * sharing. It exists since on a given platform it does uniquely identify the
249
- * layout in a simple way for i915-specific userspace.
415
+ * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
416
+ * On earlier platforms the is highly platforms specific and not useful for
417
+ * cross-driver sharing. It exists since on a given platform it does uniquely
418
+ * identify the layout in a simple way for i915-specific userspace, which
419
+ * facilitated conversion of userspace to modifiers. Additionally the exact
420
+ * format on some really old platforms is not known.
250421  */
251422 #define I915_FORMAT_MOD_X_TILED	fourcc_mod_code(INTEL, 1)
252423 
....@@ -259,9 +430,12 @@
259430  * memory can apply platform-depending swizzling of some higher address bits
260431  * into bit6.
261432  *
262
- * This format is highly platforms specific and not useful for cross-driver
263
- * sharing. It exists since on a given platform it does uniquely identify the
264
- * layout in a simple way for i915-specific userspace.
433
+ * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
434
+ * On earlier platforms the is highly platforms specific and not useful for
435
+ * cross-driver sharing. It exists since on a given platform it does uniquely
436
+ * identify the layout in a simple way for i915-specific userspace, which
437
+ * facilitated conversion of userspace to modifiers. Additionally the exact
438
+ * format on some really old platforms is not known.
265439  */
266440 #define I915_FORMAT_MOD_Y_TILED	fourcc_mod_code(INTEL, 2)
267441 
....@@ -301,6 +475,30 @@
301475 #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
302476 
303477 /*
478
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
479
+ *
480
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
481
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
482
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
483
+ * line pair. The main surface pitch is required to be a multiple of four
484
+ * Y-tile widths.
485
+ */
486
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
487
+
488
+/*
489
+ * Intel color control surfaces (CCS) for Gen-12 media compression
490
+ *
491
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
492
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
493
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
494
+ * line pair. The main surface pitch is required to be a multiple of four
495
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
496
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
497
+ * planes 2 and 3 for the respective CCS.
498
+ */
499
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
500
+
501
+/*
304502  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
305503  *
306504  * Macroblocks are laid in a Z-shape, and each pixel data is following the
....@@ -316,6 +514,15 @@
316514 #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE	fourcc_mod_code(SAMSUNG, 1)
317515 
318516 /*
517
+ * Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
518
+ *
519
+ * This is a simple tiled layout using tiles of 16x16 pixels in a row-major
520
+ * layout. For YCbCr formats Cb/Cr components are taken in such a way that
521
+ * they correspond to their 16x16 luma block.
522
+ */
523
+#define DRM_FORMAT_MOD_SAMSUNG_16_16_TILE	fourcc_mod_code(SAMSUNG, 2)
524
+
525
+/*
319526  * Qualcomm Compressed Format
320527  *
321528  * Refers to a compressed variant of the base format that is compressed.
....@@ -327,30 +534,6 @@
327534  * Entire pixel data buffer is aligned with 4k(bytes).
328535  */
329536 #define DRM_FORMAT_MOD_QCOM_COMPRESSED	fourcc_mod_code(QCOM, 1)
330
-
331
-/*
332
- * QTI DX Format
333
- *
334
- * Refers to a DX variant of the base format.
335
- * Implementation may be platform and base-format specific.
336
- */
337
-#define DRM_FORMAT_MOD_QCOM_DX	fourcc_mod_code(QCOM, 0x2)
338
-
339
-/*
340
- * QTI Tight Format
341
- *
342
- * Refers to a tightly packed variant of the base format.
343
- * Implementation may be platform and base-format specific.
344
- */
345
-#define DRM_FORMAT_MOD_QCOM_TIGHT	fourcc_mod_code(QCOM, 0x4)
346
-
347
-/*
348
- * QTI Tile Format
349
- *
350
- * Refers to a tile variant of the base format.
351
- * Implementation may be platform and base-format specific.
352
- */
353
-#define DRM_FORMAT_MOD_QCOM_TILE	fourcc_mod_code(QCOM, 0x8)
354537 
355538 /* Vivante framebuffer modifiers */
356539 
....@@ -402,7 +585,113 @@
402585 #define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
403586 
404587 /*
405
- * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
588
+ * Generalized Block Linear layout, used by desktop GPUs starting with NV50/G80,
589
+ * and Tegra GPUs starting with Tegra K1.
590
+ *
591
+ * Pixels are arranged in Groups of Bytes (GOBs).  GOB size and layout varies
592
+ * based on the architecture generation.  GOBs themselves are then arranged in
593
+ * 3D blocks, with the block dimensions (in terms of GOBs) always being a power
594
+ * of two, and hence expressible as their log2 equivalent (E.g., "2" represents
595
+ * a block depth or height of "4").
596
+ *
597
+ * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
598
+ * in full detail.
599
+ *
600
+ *       Macro
601
+ * Bits  Param Description
602
+ * ----  ----- -----------------------------------------------------------------
603
+ *
604
+ *  3:0  h     log2(height) of each block, in GOBs.  Placed here for
605
+ *             compatibility with the existing
606
+ *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
607
+ *
608
+ *  4:4  -     Must be 1, to indicate block-linear layout.  Necessary for
609
+ *             compatibility with the existing
610
+ *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
611
+ *
612
+ *  8:5  -     Reserved (To support 3D-surfaces with variable log2(depth) block
613
+ *             size).  Must be zero.
614
+ *
615
+ *             Note there is no log2(width) parameter.  Some portions of the
616
+ *             hardware support a block width of two gobs, but it is impractical
617
+ *             to use due to lack of support elsewhere, and has no known
618
+ *             benefits.
619
+ *
620
+ * 11:9  -     Reserved (To support 2D-array textures with variable array stride
621
+ *             in blocks, specified via log2(tile width in blocks)).  Must be
622
+ *             zero.
623
+ *
624
+ * 19:12 k     Page Kind.  This value directly maps to a field in the page
625
+ *             tables of all GPUs >= NV50.  It affects the exact layout of bits
626
+ *             in memory and can be derived from the tuple
627
+ *
628
+ *               (format, GPU model, compression type, samples per pixel)
629
+ *
630
+ *             Where compression type is defined below.  If GPU model were
631
+ *             implied by the format modifier, format, or memory buffer, page
632
+ *             kind would not need to be included in the modifier itself, but
633
+ *             since the modifier should define the layout of the associated
634
+ *             memory buffer independent from any device or other context, it
635
+ *             must be included here.
636
+ *
637
+ * 21:20 g     GOB Height and Page Kind Generation.  The height of a GOB changed
638
+ *             starting with Fermi GPUs.  Additionally, the mapping between page
639
+ *             kind and bit layout has changed at various points.
640
+ *
641
+ *               0 = Gob Height 8, Fermi - Volta, Tegra K1+ Page Kind mapping
642
+ *               1 = Gob Height 4, G80 - GT2XX Page Kind mapping
643
+ *               2 = Gob Height 8, Turing+ Page Kind mapping
644
+ *               3 = Reserved for future use.
645
+ *
646
+ * 22:22 s     Sector layout.  On Tegra GPUs prior to Xavier, there is a further
647
+ *             bit remapping step that occurs at an even lower level than the
648
+ *             page kind and block linear swizzles.  This causes the layout of
649
+ *             surfaces mapped in those SOC's GPUs to be incompatible with the
650
+ *             equivalent mapping on other GPUs in the same system.
651
+ *
652
+ *               0 = Tegra K1 - Tegra Parker/TX2 Layout.
653
+ *               1 = Desktop GPU and Tegra Xavier+ Layout
654
+ *
655
+ * 25:23 c     Lossless Framebuffer Compression type.
656
+ *
657
+ *               0 = none
658
+ *               1 = ROP/3D, layout 1, exact compression format implied by Page
659
+ *                   Kind field
660
+ *               2 = ROP/3D, layout 2, exact compression format implied by Page
661
+ *                   Kind field
662
+ *               3 = CDE horizontal
663
+ *               4 = CDE vertical
664
+ *               5 = Reserved for future use
665
+ *               6 = Reserved for future use
666
+ *               7 = Reserved for future use
667
+ *
668
+ * 55:25 -     Reserved for future use.  Must be zero.
669
+ */
670
+#define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \
671
+	fourcc_mod_code(NVIDIA, (0x10 | \
672
+				 ((h) & 0xf) | \
673
+				 (((k) & 0xff) << 12) | \
674
+				 (((g) & 0x3) << 20) | \
675
+				 (((s) & 0x1) << 22) | \
676
+				 (((c) & 0x7) << 23)))
677
+
678
+/* To grandfather in prior block linear format modifiers to the above layout,
679
+ * the page kind "0", which corresponds to "pitch/linear" and hence is unusable
680
+ * with block-linear layouts, is remapped within drivers to the value 0xfe,
681
+ * which corresponds to the "generic" kind used for simple single-sample
682
+ * uncompressed color formats on Fermi - Volta GPUs.
683
+ */
684
+static inline __u64
685
+drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
686
+{
687
+	if (!(modifier & 0x10) || (modifier & (0xff << 12)))
688
+		return modifier;
689
+	else
690
+		return modifier | (0xfe << 12);
691
+}
692
+
693
+/*
694
+ * 16Bx2 Block Linear layout, used by Tegra K1 and later
406695  *
407696  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
408697  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
....@@ -423,20 +712,20 @@
423712  * in full detail.
424713  */
425714 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
426
-	fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
715
+	DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(0, 0, 0, 0, (v))
427716 
428717 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
429
-	fourcc_mod_code(NVIDIA, 0x10)
718
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0)
430719 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
431
-	fourcc_mod_code(NVIDIA, 0x11)
720
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1)
432721 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
433
-	fourcc_mod_code(NVIDIA, 0x12)
722
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2)
434723 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
435
-	fourcc_mod_code(NVIDIA, 0x13)
724
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3)
436725 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
437
-	fourcc_mod_code(NVIDIA, 0x14)
726
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4)
438727 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
439
-	fourcc_mod_code(NVIDIA, 0x15)
728
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5)
440729 
441730 /*
442731  * Some Broadcom modifiers take parameters, for example the number of
....@@ -498,6 +787,10 @@
498787  * and UV.  Some SAND-using hardware stores UV in a separate tiled
499788  * image from Y to reduce the column height, which is not supported
500789  * with these modifiers.
790
+ *
791
+ * The DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT modifier is also
792
+ * supported for DRM_FORMAT_P030 where the columns remain as 128 bytes
793
+ * wide, but as this is a 10 bpp format that translates to 96 pixels.
501794  */
502795 
503796 #define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
....@@ -549,8 +842,25 @@
549842  * AFBC has several features which may be supported and/or used, which are
550843  * represented using bits in the modifier. Not all combinations are valid,
551844  * and different devices or use-cases may support different combinations.
845
+ *
846
+ * Further information on the use of AFBC modifiers can be found in
847
+ * Documentation/gpu/afbc.rst
552848  */
553
-#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode)	fourcc_mod_code(ARM, __afbc_mode)
849
+
850
+/*
851
+ * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
852
+ * modifiers) denote the category for modifiers. Currently we have only two
853
+ * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen
854
+ * different categories.
855
+ */
856
+#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
857
+	fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) & 0x000fffffffffffffULL))
858
+
859
+#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
860
+#define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
861
+
862
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
863
+	DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
554864 
555865 /*
556866  * AFBC superblock size
....@@ -644,14 +954,159 @@
644954  */
645955 #define AFBC_FORMAT_MOD_BCH     (1ULL << 11)
646956 
647
-#define ROCKCHIP_TILED_BLOCK_SIZE_MASK	0xf
957
+/* AFBC uncompressed storage mode
958
+ *
959
+ * Indicates that the buffer is using AFBC uncompressed storage mode.
960
+ * In this mode all superblock payloads in the buffer use the uncompressed
961
+ * storage mode, which is usually only used for data which cannot be compressed.
962
+ * The buffer layout is the same as for AFBC buffers without USM set, this only
963
+ * affects the storage mode of the individual superblocks. Note that even a
964
+ * buffer without USM set may use uncompressed storage mode for some or all
965
+ * superblocks, USM just guarantees it for all.
966
+ */
967
+#define AFBC_FORMAT_MOD_USM	(1ULL << 12)
968
+
969
+/*
970
+ * Arm 16x16 Block U-Interleaved modifier
971
+ *
972
+ * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
973
+ * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
974
+ * in the block are reordered.
975
+ */
976
+#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
977
+	DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
978
+
979
+/*
980
+ * Allwinner tiled modifier
981
+ *
982
+ * This tiling mode is implemented by the VPU found on all Allwinner platforms,
983
+ * codenamed sunxi. It is associated with a YUV format that uses either 2 or 3
984
+ * planes.
985
+ *
986
+ * With this tiling, the luminance samples are disposed in tiles representing
987
+ * 32x32 pixels and the chrominance samples in tiles representing 32x64 pixels.
988
+ * The pixel order in each tile is linear and the tiles are disposed linearly,
989
+ * both in row-major order.
990
+ */
991
+#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
992
+
993
+/*
994
+ * Amlogic Video Framebuffer Compression modifiers
995
+ *
996
+ * Amlogic uses a proprietary lossless image compression protocol and format
997
+ * for their hardware video codec accelerators, either video decoders or
998
+ * video input encoders.
999
+ *
1000
+ * It considerably reduces memory bandwidth while writing and reading
1001
+ * frames in memory.
1002
+ *
1003
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
1004
+ * per component YCbCr 420, single plane :
1005
+ * - DRM_FORMAT_YUV420_8BIT
1006
+ * - DRM_FORMAT_YUV420_10BIT
1007
+ *
1008
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
1009
+ * defines the options changing the layout.
1010
+ *
1011
+ * Not all combinations are valid, and different SoCs may support different
1012
+ * combinations of layout and options.
1013
+ */
1014
+#define __fourcc_mod_amlogic_layout_mask 0xff
1015
+#define __fourcc_mod_amlogic_options_shift 8
1016
+#define __fourcc_mod_amlogic_options_mask 0xff
1017
+
1018
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
1019
+	fourcc_mod_code(AMLOGIC, \
1020
+			((__layout) & __fourcc_mod_amlogic_layout_mask) | \
1021
+			(((__options) & __fourcc_mod_amlogic_options_mask) \
1022
+			 << __fourcc_mod_amlogic_options_shift))
1023
+
1024
+/* Amlogic FBC Layouts */
1025
+
1026
+/*
1027
+ * Amlogic FBC Basic Layout
1028
+ *
1029
+ * The basic layout is composed of:
1030
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
1031
+ *   superblock in default mode.
1032
+ * - a 32 bytes per 128x64 header block
1033
+ *
1034
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
1035
+ */
1036
+#define AMLOGIC_FBC_LAYOUT_BASIC		(1ULL)
1037
+
1038
+/*
1039
+ * Amlogic FBC Scatter Memory layout
1040
+ *
1041
+ * Indicates the header contains IOMMU references to the compressed
1042
+ * frames content to optimize memory access and layout.
1043
+ *
1044
+ * In this mode, only the header memory address is needed, thus the
1045
+ * content memory organization is tied to the current producer
1046
+ * execution and cannot be saved/dumped neither transferrable between
1047
+ * Amlogic SoCs supporting this modifier.
1048
+ *
1049
+ * Due to the nature of the layout, these buffers are not expected to
1050
+ * be accessible by the user-space clients, but only accessible by the
1051
+ * hardware producers and consumers.
1052
+ *
1053
+ * The user-space clients should expect a failure while trying to mmap
1054
+ * the DMA-BUF handle returned by the producer.
1055
+ */
1056
+#define AMLOGIC_FBC_LAYOUT_SCATTER		(2ULL)
1057
+
1058
+/* Amlogic FBC Layout Options Bit Mask */
1059
+
1060
+/*
1061
+ * Amlogic FBC Memory Saving mode
1062
+ *
1063
+ * Indicates the storage is packed when pixel size is multiple of word
1064
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
1065
+ * memory.
1066
+ *
1067
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
1068
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
1069
+ * the scatter layout.
1070
+ */
1071
+#define AMLOGIC_FBC_OPTION_MEM_SAVING		(1ULL << 0)
1072
+
1073
+/*
1074
+ * Rockchip modifier format
1075
+ * tiled modifier format, block size: 8x8,4x4_m0 and 4x4_m1,
1076
+ * rfbc modifier format, block size: 64x4
1077
+ *
1078
+ * bit[55,52] for Rockchip drm modifier type
1079
+ */
1080
+#define DRM_FORMAT_MOD_ROCKCHIP_TYPE_SHIFT	52
1081
+#define DRM_FORMAT_MOD_ROCKCHIP_TYPE_MASK	0xf
1082
+#define DRM_FORMAT_MOD_ROCKCHIP_TYPE_TILED	0x0
1083
+#define DRM_FORMAT_MOD_ROCKCHIP_TYPE_RFBC	0x1
1084
+
1085
+/* bit[3,0] for Rockchip drm modifier block size */
1086
+#define ROCKCHIP_TILED_BLOCK_SIZE_MASK		0xf
6481087 #define ROCKCHIP_TILED_BLOCK_SIZE_8x8		(1ULL)
6491088 #define ROCKCHIP_TILED_BLOCK_SIZE_4x4_MODE0	(2ULL)
6501089 #define ROCKCHIP_TILED_BLOCK_SIZE_4x4_MODE1	(3ULL)
6511090 
652
-#define DRM_FORMAT_MOD_ROCKCHIP_TILED(_mode) fourcc_mod_code(ROCKCHIP, _mode)
1091
+#define ROCKCHIP_RFBC_BLOCK_SIZE_64x4		(1ULL)
6531092 
654
-#define IS_ROCKCHIP_TILED_MOD(val) (((val) >> 56) == DRM_FORMAT_MOD_VENDOR_ROCKCHIP)
1093
+#define DRM_FORMAT_MOD_ROCKCHIP_CODE(__type, __val) \
1094
+	fourcc_mod_code(ROCKCHIP, ((__u64)(__type) << DRM_FORMAT_MOD_ROCKCHIP_TYPE_SHIFT) | \
1095
+			((__val) & 0x000fffffffffffffULL))
1096
+
1097
+/* Rockchip tiled modifier format */
1098
+#define DRM_FORMAT_MOD_ROCKCHIP_TILED(mode) \
1099
+	DRM_FORMAT_MOD_ROCKCHIP_CODE(DRM_FORMAT_MOD_ROCKCHIP_TYPE_TILED, mode)
1100
+#define IS_ROCKCHIP_TILED_MOD(val) \
1101
+	(((val) >> 56) == DRM_FORMAT_MOD_VENDOR_ROCKCHIP && \
1102
+	 ((val >> DRM_FORMAT_MOD_ROCKCHIP_TYPE_SHIFT) & DRM_FORMAT_MOD_ROCKCHIP_TYPE_MASK) == DRM_FORMAT_MOD_ROCKCHIP_TYPE_TILED)
1103
+
1104
+/* Rockchip rfbc modifier format */
1105
+#define DRM_FORMAT_MOD_ROCKCHIP_RFBC(mode) \
1106
+	DRM_FORMAT_MOD_ROCKCHIP_CODE(DRM_FORMAT_MOD_ROCKCHIP_TYPE_RFBC, mode)
1107
+#define IS_ROCKCHIP_RFBC_MOD(val) \
1108
+	(((val) >> 56) == DRM_FORMAT_MOD_VENDOR_ROCKCHIP && \
1109
+	 ((val >> DRM_FORMAT_MOD_ROCKCHIP_TYPE_SHIFT) & DRM_FORMAT_MOD_ROCKCHIP_TYPE_MASK) == DRM_FORMAT_MOD_ROCKCHIP_TYPE_RFBC)
6551110 
6561111 #if defined(__cplusplus)
6571112 }