[igt-dev] [PATCH i-g-t 1/2] drm-uapi: Re-synchronize drm_fourcc.h with kernel.

Fri Jun 11 14:08:59 UTC 2021

[AMD Public Use]

> -----Original Message-----
> From: Mario Kleiner <mario.kleiner.de at gmail.com>
> Sent: Friday, June 11, 2021 12:21 AM
> To: igt-dev at lists.freedesktop.org
> Cc: mario.kleiner.de at gmail.com; Ville Syrjälä <ville.syrjala at linux.intel.com>;
> Deucher, Alexander <Alexander.Deucher at amd.com>
> Subject: [PATCH i-g-t 1/2] drm-uapi: Re-synchronize drm_fourcc.h with
> kernel.
> 
> This aligns IGT's drm_fourcc.h to the latest kernel commit ff92ecf575a9
> ("drm/fourcc: Add 16 bpc fixed point framebuffer formats.") in drm-next for
> upcoming Linux 5.14.
> 
> Needed for lib/igt_fb support for testing of 16 bpc fixed point formats.
> 
> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>

Series is:
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>


> ---
>  include/drm-uapi/drm_fourcc.h | 72
> +++++++++++++++++++++++++++++++++--
>  1 file changed, 68 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-
> uapi/drm_fourcc.h index a7bc058c..f7156322 100644
> --- a/include/drm-uapi/drm_fourcc.h
> +++ b/include/drm-uapi/drm_fourcc.h
> @@ -58,6 +58,30 @@ extern "C" {
>   * may preserve meaning - such as number of planes - from the fourcc code,
>   * whereas others may not.
>   *
> + * Modifiers must uniquely encode buffer layout. In other words, a
> + buffer must
> + * match only a single modifier. A modifier must not be a subset of
> + layouts of
> + * another modifier. For instance, it's incorrect to encode pitch
> + alignment in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> + 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can
> + alias,
> + * a canonical pair needs to be defined and used by all drivers.
> + Preferred
> + * combinations are also encouraged where all combinations might lead
> + to
> + * confusion and unnecessarily reduced interoperability. An example for
> + the
> + * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
> + *
> + * There are two kinds of modifier users:
> + *
> + * - Kernel and user-space drivers: for drivers it's important that modifiers
> + *   don't alias, otherwise two drivers might support the same format but
> use
> + *   different aliases, preventing them from sharing buffers in an efficient
> + *   format.
> + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc:
> these users
> + *   see modifiers as opaque tokens they can check for equality and
> intersect.
> + *   These users musn't need to know to reason about the modifier value
> + *   (i.e. they are not expected to extract information out of the modifier).
> + *
>   * Vendors should document their modifier usage in as much detail as
>   * possible, to ensure maximum compatibility across devices, drivers and
>   * applications.
> @@ -144,6 +168,13 @@ extern "C" {
>  #define DRM_FORMAT_RGBA1010102	fourcc_code('R', 'A', '3', '0') /* [31:0]
> R:G:B:A 10:10:10:2 little endian */
>  #define DRM_FORMAT_BGRA1010102	fourcc_code('B', 'A', '3', '0') /* [31:0]
> B:G:R:A 10:10:10:2 little endian */
> 
> +/* 64 bpp RGB */
> +#define DRM_FORMAT_XRGB16161616	fourcc_code('X', 'R', '4', '8') /*
> [63:0] x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616	fourcc_code('X', 'B', '4', '8') /*
> [63:0] x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616	fourcc_code('A', 'R', '4', '8') /*
> [63:0] A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616	fourcc_code('A', 'B', '4', '8') /*
> [63:0] A:B:G:R 16:16:16:16 little endian */
> +
>  /*
>   * Floating point 64bpp RGB
>   * IEEE 754-2008 binary16 half-precision float @@ -155,6 +186,12 @@ extern
> "C" {  #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /*
> [63:0] A:R:G:B 16:16:16:16 little endian */  #define
> DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] A:B:G:R
> 16:16:16:16 little endian */
> 
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with
> +6 bits
> + * of unused padding per component:
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1',
> '0')
> +/* [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
> +
>  /* packed YCbCr */
>  #define DRM_FORMAT_YUYV		fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
> Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
>  #define DRM_FORMAT_YVYU		fourcc_code('Y', 'V', 'Y', 'U') /* [31:0]
> Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> @@ -320,7 +357,6 @@ extern "C" {
>   */
> 
>  /* Vendor Ids: */
> -#define DRM_FORMAT_MOD_NONE           0
>  #define DRM_FORMAT_MOD_VENDOR_NONE    0
>  #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
>  #define DRM_FORMAT_MOD_VENDOR_AMD     0x02
> @@ -392,6 +428,16 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_LINEAR	fourcc_mod_code(NONE, 0)
> 
> +/*
> + * Deprecated: use DRM_FORMAT_MOD_LINEAR instead
> + *
> + * The "none" format modifier doesn't actually mean that the modifier
> +is
> + * implicit, instead it means that the layout is linear. Whether
> +modifiers are
> + * used is out-of-band information carried in an API-specific way (e.g.
> +in a
> + * flag for drm_mode_fb_cmd2).
> + */
> +#define DRM_FORMAT_MOD_NONE	0
> +
>  /* Intel framebuffer modifiers */
> 
>  /*
> @@ -488,6 +534,25 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
> fourcc_mod_code(INTEL, 7)
> 
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> + * compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
> +linear
> + * and at index 1. The clear color is stored at index 2, and the pitch
> +should
> + * be ignored. The clear color structure is 256 bits. The first 128
> +bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> +represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and
> +generates
> + * the converted clear color of size 64 bits. The first 32 bits store
> +the Lower
> + * Converted Clear Color value and the next 32 bits store the Higher
> +Converted
> + * Clear Color value when applicable. The Converted Clear Color values
> +are
> + * consumed by the DE. The last 64 bits are used to store Color Discard
> +Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache
> +line
> + * corresponds to an area of 4x1 tiles in the main surface. The main
> +surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC
> fourcc_mod_code(INTEL,
> +8)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
> @@ -997,9 +1062,9 @@
> drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
>   * Not all combinations are valid, and different SoCs may support different
>   * combinations of layout and options.
>   */
> -#define __fourcc_mod_amlogic_layout_mask 0xf
> +#define __fourcc_mod_amlogic_layout_mask 0xff
>  #define __fourcc_mod_amlogic_options_shift 8 -#define
> __fourcc_mod_amlogic_options_mask 0xf
> +#define __fourcc_mod_amlogic_options_mask 0xff
> 
>  #define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
>  	fourcc_mod_code(AMLOGIC, \
> @@ -1195,4 +1260,3 @@
> drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)  #endif
> 
>  #endif /* DRM_FOURCC_H */
> -
> --
> 2.25.1