blame | history | patch | commit | commitdiff
hc
2023-12-06 08f87f769b595151be1afeff53e144f543faa614 
 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,58 @@
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
+/* 3 plane non-subsampled (444) YCbCr
277
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
278
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
279
+ * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
280
+ * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
281
+ */
282
+#define DRM_FORMAT_Q410		fourcc_code('Q', '4', '1', '0')
283
+
284
+/* 3 plane non-subsampled (444) YCrCb
285
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
286
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
287
+ * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
288
+ * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
289
+ */
290
+#define DRM_FORMAT_Q401		fourcc_code('Q', '4', '0', '1')
158291 
159292 /*
160293  * 3 plane YCbCr
....@@ -199,7 +332,10 @@
199332 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
200333 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
201334 #define DRM_FORMAT_MOD_VENDOR_ARM     0x08
335
+#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
336
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
202337 #define DRM_FORMAT_MOD_VENDOR_ROCKCHIP 0x0b
338
+
203339 /* add more to the end as needed */
204340 
205341 #define DRM_FORMAT_RESERVED	      ((1ULL << 56) - 1)
....@@ -213,7 +349,32 @@
213349  * When adding a new token please document the layout with a code comment,
214350  * similar to the fourcc codes above. drm_fourcc.h is considered the
215351  * authoritative source for all of these.
352
+ *
353
+ * Generic modifier names:
354
+ *
355
+ * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names
356
+ * for layouts which are common across multiple vendors. To preserve
357
+ * compatibility, in cases where a vendor-specific definition already exists and
358
+ * a generic name for it is desired, the common name is a purely symbolic alias
359
+ * and must use the same numerical value as the original definition.
360
+ *
361
+ * Note that generic names should only be used for modifiers which describe
362
+ * generic layouts (such as pixel re-ordering), which may have
363
+ * independently-developed support across multiple vendors.
364
+ *
365
+ * In future cases where a generic layout is identified before merging with a
366
+ * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
367
+ * 'NONE' could be considered. This should only be for obvious, exceptional
368
+ * cases to avoid polluting the 'GENERIC' namespace with modifiers which only
369
+ * apply to a single vendor.
370
+ *
371
+ * Generic names should not be used for cases where multiple hardware vendors
372
+ * have implementations of the same standardised compression scheme (such as
373
+ * AFBC). In those cases, all implementations should use the same format
374
+ * modifier(s), reflecting the vendor of the standard.
216375  */
376
+
377
+#define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
217378 
218379 /*
219380  * Invalid Modifier
....@@ -244,9 +405,12 @@
244405  * a platform-dependent stride. On top of that the memory can apply
245406  * platform-depending swizzling of some higher address bits into bit6.
246407  *
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.
408
+ * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
409
+ * On earlier platforms the is highly platforms specific and not useful for
410
+ * cross-driver sharing. It exists since on a given platform it does uniquely
411
+ * identify the layout in a simple way for i915-specific userspace, which
412
+ * facilitated conversion of userspace to modifiers. Additionally the exact
413
+ * format on some really old platforms is not known.
250414  */
251415 #define I915_FORMAT_MOD_X_TILED	fourcc_mod_code(INTEL, 1)
252416 
....@@ -259,9 +423,12 @@
259423  * memory can apply platform-depending swizzling of some higher address bits
260424  * into bit6.
261425  *
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.
426
+ * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
427
+ * On earlier platforms the is highly platforms specific and not useful for
428
+ * cross-driver sharing. It exists since on a given platform it does uniquely
429
+ * identify the layout in a simple way for i915-specific userspace, which
430
+ * facilitated conversion of userspace to modifiers. Additionally the exact
431
+ * format on some really old platforms is not known.
265432  */
266433 #define I915_FORMAT_MOD_Y_TILED	fourcc_mod_code(INTEL, 2)
267434 
....@@ -301,6 +468,30 @@
301468 #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
302469 
303470 /*
471
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
472
+ *
473
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
474
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
475
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
476
+ * line pair. The main surface pitch is required to be a multiple of four
477
+ * Y-tile widths.
478
+ */
479
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
480
+
481
+/*
482
+ * Intel color control surfaces (CCS) for Gen-12 media compression
483
+ *
484
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
485
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
486
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
487
+ * line pair. The main surface pitch is required to be a multiple of four
488
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
489
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
490
+ * planes 2 and 3 for the respective CCS.
491
+ */
492
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
493
+
494
+/*
304495  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
305496  *
306497  * Macroblocks are laid in a Z-shape, and each pixel data is following the
....@@ -316,6 +507,15 @@
316507 #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE	fourcc_mod_code(SAMSUNG, 1)
317508 
318509 /*
510
+ * Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
511
+ *
512
+ * This is a simple tiled layout using tiles of 16x16 pixels in a row-major
513
+ * layout. For YCbCr formats Cb/Cr components are taken in such a way that
514
+ * they correspond to their 16x16 luma block.
515
+ */
516
+#define DRM_FORMAT_MOD_SAMSUNG_16_16_TILE	fourcc_mod_code(SAMSUNG, 2)
517
+
518
+/*
319519  * Qualcomm Compressed Format
320520  *
321521  * Refers to a compressed variant of the base format that is compressed.
....@@ -327,30 +527,6 @@
327527  * Entire pixel data buffer is aligned with 4k(bytes).
328528  */
329529 #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)
354530 
355531 /* Vivante framebuffer modifiers */
356532 
....@@ -402,7 +578,113 @@
402578 #define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
403579 
404580 /*
405
- * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
581
+ * Generalized Block Linear layout, used by desktop GPUs starting with NV50/G80,
582
+ * and Tegra GPUs starting with Tegra K1.
583
+ *
584
+ * Pixels are arranged in Groups of Bytes (GOBs).  GOB size and layout varies
585
+ * based on the architecture generation.  GOBs themselves are then arranged in
586
+ * 3D blocks, with the block dimensions (in terms of GOBs) always being a power
587
+ * of two, and hence expressible as their log2 equivalent (E.g., "2" represents
588
+ * a block depth or height of "4").
589
+ *
590
+ * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
591
+ * in full detail.
592
+ *
593
+ *       Macro
594
+ * Bits  Param Description
595
+ * ----  ----- -----------------------------------------------------------------
596
+ *
597
+ *  3:0  h     log2(height) of each block, in GOBs.  Placed here for
598
+ *             compatibility with the existing
599
+ *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
600
+ *
601
+ *  4:4  -     Must be 1, to indicate block-linear layout.  Necessary for
602
+ *             compatibility with the existing
603
+ *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
604
+ *
605
+ *  8:5  -     Reserved (To support 3D-surfaces with variable log2(depth) block
606
+ *             size).  Must be zero.
607
+ *
608
+ *             Note there is no log2(width) parameter.  Some portions of the
609
+ *             hardware support a block width of two gobs, but it is impractical
610
+ *             to use due to lack of support elsewhere, and has no known
611
+ *             benefits.
612
+ *
613
+ * 11:9  -     Reserved (To support 2D-array textures with variable array stride
614
+ *             in blocks, specified via log2(tile width in blocks)).  Must be
615
+ *             zero.
616
+ *
617
+ * 19:12 k     Page Kind.  This value directly maps to a field in the page
618
+ *             tables of all GPUs >= NV50.  It affects the exact layout of bits
619
+ *             in memory and can be derived from the tuple
620
+ *
621
+ *               (format, GPU model, compression type, samples per pixel)
622
+ *
623
+ *             Where compression type is defined below.  If GPU model were
624
+ *             implied by the format modifier, format, or memory buffer, page
625
+ *             kind would not need to be included in the modifier itself, but
626
+ *             since the modifier should define the layout of the associated
627
+ *             memory buffer independent from any device or other context, it
628
+ *             must be included here.
629
+ *
630
+ * 21:20 g     GOB Height and Page Kind Generation.  The height of a GOB changed
631
+ *             starting with Fermi GPUs.  Additionally, the mapping between page
632
+ *             kind and bit layout has changed at various points.
633
+ *
634
+ *               0 = Gob Height 8, Fermi - Volta, Tegra K1+ Page Kind mapping
635
+ *               1 = Gob Height 4, G80 - GT2XX Page Kind mapping
636
+ *               2 = Gob Height 8, Turing+ Page Kind mapping
637
+ *               3 = Reserved for future use.
638
+ *
639
+ * 22:22 s     Sector layout.  On Tegra GPUs prior to Xavier, there is a further
640
+ *             bit remapping step that occurs at an even lower level than the
641
+ *             page kind and block linear swizzles.  This causes the layout of
642
+ *             surfaces mapped in those SOC's GPUs to be incompatible with the
643
+ *             equivalent mapping on other GPUs in the same system.
644
+ *
645
+ *               0 = Tegra K1 - Tegra Parker/TX2 Layout.
646
+ *               1 = Desktop GPU and Tegra Xavier+ Layout
647
+ *
648
+ * 25:23 c     Lossless Framebuffer Compression type.
649
+ *
650
+ *               0 = none
651
+ *               1 = ROP/3D, layout 1, exact compression format implied by Page
652
+ *                   Kind field
653
+ *               2 = ROP/3D, layout 2, exact compression format implied by Page
654
+ *                   Kind field
655
+ *               3 = CDE horizontal
656
+ *               4 = CDE vertical
657
+ *               5 = Reserved for future use
658
+ *               6 = Reserved for future use
659
+ *               7 = Reserved for future use
660
+ *
661
+ * 55:25 -     Reserved for future use.  Must be zero.
662
+ */
663
+#define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \
664
+	fourcc_mod_code(NVIDIA, (0x10 | \
665
+				 ((h) & 0xf) | \
666
+				 (((k) & 0xff) << 12) | \
667
+				 (((g) & 0x3) << 20) | \
668
+				 (((s) & 0x1) << 22) | \
669
+				 (((c) & 0x7) << 23)))
670
+
671
+/* To grandfather in prior block linear format modifiers to the above layout,
672
+ * the page kind "0", which corresponds to "pitch/linear" and hence is unusable
673
+ * with block-linear layouts, is remapped within drivers to the value 0xfe,
674
+ * which corresponds to the "generic" kind used for simple single-sample
675
+ * uncompressed color formats on Fermi - Volta GPUs.
676
+ */
677
+static inline __u64
678
+drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
679
+{
680
+	if (!(modifier & 0x10) || (modifier & (0xff << 12)))
681
+		return modifier;
682
+	else
683
+		return modifier | (0xfe << 12);
684
+}
685
+
686
+/*
687
+ * 16Bx2 Block Linear layout, used by Tegra K1 and later
406688  *
407689  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
408690  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
....@@ -423,20 +705,20 @@
423705  * in full detail.
424706  */
425707 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
426
-	fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
708
+	DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(0, 0, 0, 0, (v))
427709 
428710 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
429
-	fourcc_mod_code(NVIDIA, 0x10)
711
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0)
430712 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
431
-	fourcc_mod_code(NVIDIA, 0x11)
713
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1)
432714 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
433
-	fourcc_mod_code(NVIDIA, 0x12)
715
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2)
434716 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
435
-	fourcc_mod_code(NVIDIA, 0x13)
717
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3)
436718 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
437
-	fourcc_mod_code(NVIDIA, 0x14)
719
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4)
438720 #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
439
-	fourcc_mod_code(NVIDIA, 0x15)
721
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5)
440722 
441723 /*
442724  * Some Broadcom modifiers take parameters, for example the number of
....@@ -549,8 +831,25 @@
549831  * AFBC has several features which may be supported and/or used, which are
550832  * represented using bits in the modifier. Not all combinations are valid,
551833  * and different devices or use-cases may support different combinations.
834
+ *
835
+ * Further information on the use of AFBC modifiers can be found in
836
+ * Documentation/gpu/afbc.rst
552837  */
553
-#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode)	fourcc_mod_code(ARM, __afbc_mode)
838
+
839
+/*
840
+ * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
841
+ * modifiers) denote the category for modifiers. Currently we have only two
842
+ * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen
843
+ * different categories.
844
+ */
845
+#define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
846
+	fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) & 0x000fffffffffffffULL))
847
+
848
+#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
849
+#define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
850
+
851
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
852
+	DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
554853 
555854 /*
556855  * AFBC superblock size
....@@ -644,7 +943,123 @@
644943  */
645944 #define AFBC_FORMAT_MOD_BCH     (1ULL << 11)
646945 
647
-#define ROCKCHIP_TILED_BLOCK_SIZE_MASK	0xf
946
+/* AFBC uncompressed storage mode
947
+ *
948
+ * Indicates that the buffer is using AFBC uncompressed storage mode.
949
+ * In this mode all superblock payloads in the buffer use the uncompressed
950
+ * storage mode, which is usually only used for data which cannot be compressed.
951
+ * The buffer layout is the same as for AFBC buffers without USM set, this only
952
+ * affects the storage mode of the individual superblocks. Note that even a
953
+ * buffer without USM set may use uncompressed storage mode for some or all
954
+ * superblocks, USM just guarantees it for all.
955
+ */
956
+#define AFBC_FORMAT_MOD_USM	(1ULL << 12)
957
+
958
+/*
959
+ * Arm 16x16 Block U-Interleaved modifier
960
+ *
961
+ * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
962
+ * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
963
+ * in the block are reordered.
964
+ */
965
+#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
966
+	DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
967
+
968
+/*
969
+ * Allwinner tiled modifier
970
+ *
971
+ * This tiling mode is implemented by the VPU found on all Allwinner platforms,
972
+ * codenamed sunxi. It is associated with a YUV format that uses either 2 or 3
973
+ * planes.
974
+ *
975
+ * With this tiling, the luminance samples are disposed in tiles representing
976
+ * 32x32 pixels and the chrominance samples in tiles representing 32x64 pixels.
977
+ * The pixel order in each tile is linear and the tiles are disposed linearly,
978
+ * both in row-major order.
979
+ */
980
+#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
981
+
982
+/*
983
+ * Amlogic Video Framebuffer Compression modifiers
984
+ *
985
+ * Amlogic uses a proprietary lossless image compression protocol and format
986
+ * for their hardware video codec accelerators, either video decoders or
987
+ * video input encoders.
988
+ *
989
+ * It considerably reduces memory bandwidth while writing and reading
990
+ * frames in memory.
991
+ *
992
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
993
+ * per component YCbCr 420, single plane :
994
+ * - DRM_FORMAT_YUV420_8BIT
995
+ * - DRM_FORMAT_YUV420_10BIT
996
+ *
997
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
998
+ * defines the options changing the layout.
999
+ *
1000
+ * Not all combinations are valid, and different SoCs may support different
1001
+ * combinations of layout and options.
1002
+ */
1003
+#define __fourcc_mod_amlogic_layout_mask 0xff
1004
+#define __fourcc_mod_amlogic_options_shift 8
1005
+#define __fourcc_mod_amlogic_options_mask 0xff
1006
+
1007
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
1008
+	fourcc_mod_code(AMLOGIC, \
1009
+			((__layout) & __fourcc_mod_amlogic_layout_mask) | \
1010
+			(((__options) & __fourcc_mod_amlogic_options_mask) \
1011
+			 << __fourcc_mod_amlogic_options_shift))
1012
+
1013
+/* Amlogic FBC Layouts */
1014
+
1015
+/*
1016
+ * Amlogic FBC Basic Layout
1017
+ *
1018
+ * The basic layout is composed of:
1019
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
1020
+ *   superblock in default mode.
1021
+ * - a 32 bytes per 128x64 header block
1022
+ *
1023
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
1024
+ */
1025
+#define AMLOGIC_FBC_LAYOUT_BASIC		(1ULL)
1026
+
1027
+/*
1028
+ * Amlogic FBC Scatter Memory layout
1029
+ *
1030
+ * Indicates the header contains IOMMU references to the compressed
1031
+ * frames content to optimize memory access and layout.
1032
+ *
1033
+ * In this mode, only the header memory address is needed, thus the
1034
+ * content memory organization is tied to the current producer
1035
+ * execution and cannot be saved/dumped neither transferrable between
1036
+ * Amlogic SoCs supporting this modifier.
1037
+ *
1038
+ * Due to the nature of the layout, these buffers are not expected to
1039
+ * be accessible by the user-space clients, but only accessible by the
1040
+ * hardware producers and consumers.
1041
+ *
1042
+ * The user-space clients should expect a failure while trying to mmap
1043
+ * the DMA-BUF handle returned by the producer.
1044
+ */
1045
+#define AMLOGIC_FBC_LAYOUT_SCATTER		(2ULL)
1046
+
1047
+/* Amlogic FBC Layout Options Bit Mask */
1048
+
1049
+/*
1050
+ * Amlogic FBC Memory Saving mode
1051
+ *
1052
+ * Indicates the storage is packed when pixel size is multiple of word
1053
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
1054
+ * memory.
1055
+ *
1056
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
1057
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
1058
+ * the scatter layout.
1059
+ */
1060
+#define AMLOGIC_FBC_OPTION_MEM_SAVING		(1ULL << 0)
1061
+
1062
+#define ROCKCHIP_TILED_BLOCK_SIZE_MASK		0xf
6481063 #define ROCKCHIP_TILED_BLOCK_SIZE_8x8		(1ULL)
6491064 #define ROCKCHIP_TILED_BLOCK_SIZE_4x4_MODE0	(2ULL)
6501065 #define ROCKCHIP_TILED_BLOCK_SIZE_4x4_MODE1	(3ULL)