| Message ID | 20251204-headers-update-v6-18-v1-1-93135d14a081@ideasonboard.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
Quoting Jacopo Mondi (2025-12-04 15:54:14) > Update drm_fourcc.h to Linux kernel version v6.18. > > As the upstream drm_fourcc.h version doesn't include formats > definitions for RAW Bayer formats, we have to re-define some of > the symbols we kept downstream as new symbols have been added in > mainline with the same values. > > In particular: > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > and > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f Are these just our 'local' references to them ? I don't think we're actually using them in a kernel interface are we ? In which case can we put them in private numerical namespace so they don't have to be re-chosen every update? -- Kieran > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > --- > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 182 insertions(+), 13 deletions(-) > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > --- a/include/linux/drm_fourcc.h > +++ b/include/linux/drm_fourcc.h > @@ -222,7 +222,7 @@ extern "C" { > #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 > + * Half-Floating point - 16b/component > * IEEE 754-2008 binary16 half-precision float > * [15:0] sign:exponent:mantissa 1:5:10 > */ > @@ -232,6 +232,20 @@ 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 */ > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > + > +/* > + * Floating point - 32b/component > + * IEEE 754-2008 binary32 float > + * [31:0] sign:exponent:mantissa 1:8:23 > + */ > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > + > /* > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > * of unused padding per component: > @@ -381,6 +395,42 @@ extern "C" { > */ > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > +/* > + * 3 plane YCbCr LSB aligned > + * In order to use these formats in a similar fashion to MSB aligned ones > + * implementation can multiply the values by 2^6=64. For that reason the padding > + * must only contain zeros. > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > + */ > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > + > +/* > + * 3 plane YCbCr LSB aligned > + * In order to use these formats in a similar fashion to MSB aligned ones > + * implementation can multiply the values by 2^4=16. For that reason the padding > + * must only contain zeros. > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > + */ > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > + > +/* > + * 3 plane YCbCr > + * index 0 = Y plane, [15:0] Y little endian > + * index 1 = Cr plane, [15:0] Cr little endian > + * index 2 = Cb plane, [15:0] Cb little endian > + */ > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > + > /* > * 3 plane YCbCr > * index 0: Y plane, [7:0] Y > @@ -489,8 +539,10 @@ extern "C" { > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > /* add more to the end as needed */ > > @@ -772,6 +824,31 @@ extern "C" { > */ > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > +/* > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > + * on integrated graphics > + * > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > + * GEM object in a reserved memory area dedicated for the storage of the > + * CCS data for all compressible GEM objects. > + */ > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > + > +/* > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > + * on discrete graphics > + * > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > + * GEM object in a reserved memory area dedicated for the storage of the > + * CCS data for all compressible GEM objects. The GEM object must be stored in > + * contiguous memory with a size aligned to 64KB > + */ > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > + > /* > * IPU3 Bayer packing layout > * > @@ -780,7 +857,7 @@ extern "C" { > * the 6 most significant bits in the last byte unused. The format is little > * endian. > */ > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > /* > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > @@ -978,14 +1055,20 @@ extern "C" { > * 2 = Gob Height 8, Turing+ Page Kind mapping > * 3 = Reserved for future use. > * > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > - * bit remapping step that occurs at an even lower level than the > - * page kind and block linear swizzles. This causes the layout of > - * surfaces mapped in those SOC's GPUs to be incompatible with the > - * equivalent mapping on other GPUs in the same system. > - * > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > - * 1 = Desktop GPU and Tegra Xavier+ Layout > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > + * 26:27 at an even lower level than the page kind and block linear > + * swizzles. This causes the bit arrangement of surfaces in memory > + * to differ subtly, and prevents direct sharing of surfaces between > + * GPUs with different layouts. > + * > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > + * 4 = Reserved for future use. > + * 5 = Reserved for future use. > + * 6 = Reserved for future use. > + * 7 = Reserved for future use. > * > * 25:23 c Lossless Framebuffer Compression type. > * > @@ -1000,7 +1083,7 @@ extern "C" { > * 6 = Reserved for future use > * 7 = Reserved for future use > * > - * 55:25 - Reserved for future use. Must be zero. > + * 55:28 - Reserved for future use. Must be zero. > */ > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > fourcc_mod_code(NVIDIA, (0x10 | \ > @@ -1008,6 +1091,7 @@ extern "C" { > (((k) & 0xff) << 12) | \ > (((g) & 0x3) << 20) | \ > (((s) & 0x1) << 22) | \ > + (((s) & 0x6) << 25) | \ > (((c) & 0x7) << 23))) > > /* To grandfather in prior block linear format modifiers to the above layout, > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > */ > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > +/* MediaTek modifiers > + * Bits Parameter Notes > + * ----- ------------------------ --------------------------------------------- > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > + * > + */ > + > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > + > +/* > + * MediaTek Tiled Modifier > + * The lowest 8 bits of the modifier is used to specify the tiling > + * layout. Only the 16L_32S tiling is used for now, but we define an > + * "untiled" version and leave room for future expansion. > + */ > +#define MTK_FMT_MOD_TILE_MASK 0xf > +#define MTK_FMT_MOD_TILE_NONE 0x0 > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > + > +/* > + * Bits 8-15 specify compression options > + */ > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > + > +/* > + * Bits 16-23 specify how the bits of 10 bit formats are > + * stored out in memory > + */ > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > + > +/* alias for the most common tiling format */ > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > + > +/* > + * Apple GPU-tiled layouts. > + * > + * Apple GPUs support nonlinear tilings with optional lossless compression. > + * > + * GPU-tiled images are divided into 16KiB tiles: > + * > + * Bytes per pixel Tile size > + * --------------- --------- > + * 1 128x128 > + * 2 128x64 > + * 4 64x64 > + * 8 64x32 > + * 16 32x32 > + * > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > + * > + * Compressed images pad the body to 128-bytes and are immediately followed by a > + * metadata section. The metadata section rounds the image dimensions to > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > + * Subtiles are interleaved (Morton order). > + * > + * All images are 128-byte aligned. > + * > + * These layouts fundamentally do not have meaningful strides. No matter how we > + * specify strides for these layouts, userspace unaware of Apple image layouts > + * will be unable to use correctly the specified stride for any purpose. > + * Userspace aware of the image layouts do not use strides. The most "correct" > + * convention would be setting the image stride to 0. Unfortunately, some > + * software assumes the stride is at least (width * bytes per pixel). We > + * therefore require that stride equals (width * bytes per pixel). Since the > + * stride is arbitrary here, we pick the simplest convention. > + * > + * Although containing two sections, compressed image layouts are treated in > + * software as a single plane. This is modelled after AFBC, a similar > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > + * only generate more confusion, as software does not treat the image this way. > + * > + * For detailed information on the hardware image layouts, see > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > + */ > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > + > /* > * AMD modifiers > * > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > */ > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27 > > -- > 2.51.1 >
On Tue, Dec 09, 2025 at 11:52:07AM +0000, Kieran Bingham wrote: > Quoting Jacopo Mondi (2025-12-04 15:54:14) > > Update drm_fourcc.h to Linux kernel version v6.18. > > > > As the upstream drm_fourcc.h version doesn't include formats > > definitions for RAW Bayer formats, we have to re-define some of > > the symbols we kept downstream as new symbols have been added in > > mainline with the same values. > > > > In particular: > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > and > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > Are these just our 'local' references to them ? I don't think we're > actually using them in a kernel interface are we ? > > In which case can we put them in private numerical namespace so they > don't have to be re-chosen every update? The value of the macros are part of the ABI I'm afraid, see the generated include/libcamera/formats.h file. We'll need to upstream modifiers where they make sense, but we never reached a conclusion on whether or not bayer formats should be upstreamed in DRM or if they should use a generic format with the bayer pattern being conveyed out-of-band. Given that V4L2 is moving in that direction, it would make sense to do so in the libcamera API too in my opinion. We would still need the modifier to indicate compression though. > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > --- > > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 182 insertions(+), 13 deletions(-) > > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > > --- a/include/linux/drm_fourcc.h > > +++ b/include/linux/drm_fourcc.h > > @@ -222,7 +222,7 @@ extern "C" { > > #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 > > + * Half-Floating point - 16b/component > > * IEEE 754-2008 binary16 half-precision float > > * [15:0] sign:exponent:mantissa 1:5:10 > > */ > > @@ -232,6 +232,20 @@ 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 */ > > > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > > + > > +/* > > + * Floating point - 32b/component > > + * IEEE 754-2008 binary32 float > > + * [31:0] sign:exponent:mantissa 1:8:23 > > + */ > > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > > + > > /* > > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > > * of unused padding per component: > > @@ -381,6 +395,42 @@ extern "C" { > > */ > > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > > > +/* > > + * 3 plane YCbCr LSB aligned > > + * In order to use these formats in a similar fashion to MSB aligned ones > > + * implementation can multiply the values by 2^6=64. For that reason the padding > > + * must only contain zeros. > > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > > + */ > > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > + > > +/* > > + * 3 plane YCbCr LSB aligned > > + * In order to use these formats in a similar fashion to MSB aligned ones > > + * implementation can multiply the values by 2^4=16. For that reason the padding > > + * must only contain zeros. > > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > > + */ > > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > + > > +/* > > + * 3 plane YCbCr > > + * index 0 = Y plane, [15:0] Y little endian > > + * index 1 = Cr plane, [15:0] Cr little endian > > + * index 2 = Cb plane, [15:0] Cb little endian > > + */ > > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > + > > /* > > * 3 plane YCbCr > > * index 0: Y plane, [7:0] Y > > @@ -489,8 +539,10 @@ extern "C" { > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > /* add more to the end as needed */ > > > > @@ -772,6 +824,31 @@ extern "C" { > > */ > > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > > > +/* > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > + * on integrated graphics > > + * > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > + * GEM object in a reserved memory area dedicated for the storage of the > > + * CCS data for all compressible GEM objects. > > + */ > > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > > + > > +/* > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > + * on discrete graphics > > + * > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > + * GEM object in a reserved memory area dedicated for the storage of the > > + * CCS data for all compressible GEM objects. The GEM object must be stored in > > + * contiguous memory with a size aligned to 64KB > > + */ > > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > > + > > /* > > * IPU3 Bayer packing layout > > * > > @@ -780,7 +857,7 @@ extern "C" { > > * the 6 most significant bits in the last byte unused. The format is little > > * endian. > > */ > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > /* > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > @@ -978,14 +1055,20 @@ extern "C" { > > * 2 = Gob Height 8, Turing+ Page Kind mapping > > * 3 = Reserved for future use. > > * > > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > > - * bit remapping step that occurs at an even lower level than the > > - * page kind and block linear swizzles. This causes the layout of > > - * surfaces mapped in those SOC's GPUs to be incompatible with the > > - * equivalent mapping on other GPUs in the same system. > > - * > > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > > - * 1 = Desktop GPU and Tegra Xavier+ Layout > > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > > + * 26:27 at an even lower level than the page kind and block linear > > + * swizzles. This causes the bit arrangement of surfaces in memory > > + * to differ subtly, and prevents direct sharing of surfaces between > > + * GPUs with different layouts. > > + * > > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > > + * 4 = Reserved for future use. > > + * 5 = Reserved for future use. > > + * 6 = Reserved for future use. > > + * 7 = Reserved for future use. > > * > > * 25:23 c Lossless Framebuffer Compression type. > > * > > @@ -1000,7 +1083,7 @@ extern "C" { > > * 6 = Reserved for future use > > * 7 = Reserved for future use > > * > > - * 55:25 - Reserved for future use. Must be zero. > > + * 55:28 - Reserved for future use. Must be zero. > > */ > > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > > fourcc_mod_code(NVIDIA, (0x10 | \ > > @@ -1008,6 +1091,7 @@ extern "C" { > > (((k) & 0xff) << 12) | \ > > (((g) & 0x3) << 20) | \ > > (((s) & 0x1) << 22) | \ > > + (((s) & 0x6) << 25) | \ > > (((c) & 0x7) << 23))) > > > > /* To grandfather in prior block linear format modifiers to the above layout, > > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > */ > > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > > > +/* MediaTek modifiers > > + * Bits Parameter Notes > > + * ----- ------------------------ --------------------------------------------- > > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > > + * > > + */ > > + > > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > > + > > +/* > > + * MediaTek Tiled Modifier > > + * The lowest 8 bits of the modifier is used to specify the tiling > > + * layout. Only the 16L_32S tiling is used for now, but we define an > > + * "untiled" version and leave room for future expansion. > > + */ > > +#define MTK_FMT_MOD_TILE_MASK 0xf > > +#define MTK_FMT_MOD_TILE_NONE 0x0 > > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > > + > > +/* > > + * Bits 8-15 specify compression options > > + */ > > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > > + > > +/* > > + * Bits 16-23 specify how the bits of 10 bit formats are > > + * stored out in memory > > + */ > > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > > + > > +/* alias for the most common tiling format */ > > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > > + > > +/* > > + * Apple GPU-tiled layouts. > > + * > > + * Apple GPUs support nonlinear tilings with optional lossless compression. > > + * > > + * GPU-tiled images are divided into 16KiB tiles: > > + * > > + * Bytes per pixel Tile size > > + * --------------- --------- > > + * 1 128x128 > > + * 2 128x64 > > + * 4 64x64 > > + * 8 64x32 > > + * 16 32x32 > > + * > > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > > + * > > + * Compressed images pad the body to 128-bytes and are immediately followed by a > > + * metadata section. The metadata section rounds the image dimensions to > > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > > + * Subtiles are interleaved (Morton order). > > + * > > + * All images are 128-byte aligned. > > + * > > + * These layouts fundamentally do not have meaningful strides. No matter how we > > + * specify strides for these layouts, userspace unaware of Apple image layouts > > + * will be unable to use correctly the specified stride for any purpose. > > + * Userspace aware of the image layouts do not use strides. The most "correct" > > + * convention would be setting the image stride to 0. Unfortunately, some > > + * software assumes the stride is at least (width * bytes per pixel). We > > + * therefore require that stride equals (width * bytes per pixel). Since the > > + * stride is arbitrary here, we pick the simplest convention. > > + * > > + * Although containing two sections, compressed image layouts are treated in > > + * software as a single plane. This is modelled after AFBC, a similar > > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > > + * only generate more confusion, as software does not treat the image this way. > > + * > > + * For detailed information on the hardware image layouts, see > > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > > + */ > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > > + > > /* > > * AMD modifiers > > * > > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > > */ > > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27
Quoting Laurent Pinchart (2025-12-09 12:06:08) > On Tue, Dec 09, 2025 at 11:52:07AM +0000, Kieran Bingham wrote: > > Quoting Jacopo Mondi (2025-12-04 15:54:14) > > > Update drm_fourcc.h to Linux kernel version v6.18. > > > > > > As the upstream drm_fourcc.h version doesn't include formats > > > definitions for RAW Bayer formats, we have to re-define some of > > > the symbols we kept downstream as new symbols have been added in > > > mainline with the same values. > > > > > > In particular: > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > and > > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > Are these just our 'local' references to them ? I don't think we're > > actually using them in a kernel interface are we ? > > > > In which case can we put them in private numerical namespace so they > > don't have to be re-chosen every update? > > The value of the macros are part of the ABI I'm afraid, see the > generated include/libcamera/formats.h file. We'll need to upstream Yes, libcamera ABI - but not /kernel/ ABI - there's no kernel side to these numbers in use right now right? This is just how we're representing values in libcamera... Or do we have to align this with the Raspberry Pi BSP for instance? > modifiers where they make sense, but we never reached a conclusion on > whether or not bayer formats should be upstreamed in DRM or if they > should use a generic format with the bayer pattern being conveyed > out-of-band. Given that V4L2 is moving in that direction, it would make > sense to do so in the libcamera API too in my opinion. We would still > need the modifier to indicate compression though. if we use 'the next available number' then this ABI break will happen on every update. If we use some 'higher/private' value - then we don't have to change it when new values are added to drm_fourcc.h on the assumption that getting any upstream solution here will take N^2 releases. Yes, of course we would have to change these again when we finally do get somethign upstream - but my question about using some private numbers is so that we can avoid changing them every 8 weeks/every rebase. -- Kieran > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > > --- > > > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > > > 1 file changed, 182 insertions(+), 13 deletions(-) > > > > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > > > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > > > --- a/include/linux/drm_fourcc.h > > > +++ b/include/linux/drm_fourcc.h > > > @@ -222,7 +222,7 @@ extern "C" { > > > #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 > > > + * Half-Floating point - 16b/component > > > * IEEE 754-2008 binary16 half-precision float > > > * [15:0] sign:exponent:mantissa 1:5:10 > > > */ > > > @@ -232,6 +232,20 @@ 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 */ > > > > > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > > > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > > > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > > > + > > > +/* > > > + * Floating point - 32b/component > > > + * IEEE 754-2008 binary32 float > > > + * [31:0] sign:exponent:mantissa 1:8:23 > > > + */ > > > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > > > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > > > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > > > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > > > + > > > /* > > > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > > > * of unused padding per component: > > > @@ -381,6 +395,42 @@ extern "C" { > > > */ > > > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > > > > > +/* > > > + * 3 plane YCbCr LSB aligned > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > + * implementation can multiply the values by 2^6=64. For that reason the padding > > > + * must only contain zeros. > > > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > > > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > > > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > > > + */ > > > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > + > > > +/* > > > + * 3 plane YCbCr LSB aligned > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > + * implementation can multiply the values by 2^4=16. For that reason the padding > > > + * must only contain zeros. > > > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > > > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > > > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > > > + */ > > > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > + > > > +/* > > > + * 3 plane YCbCr > > > + * index 0 = Y plane, [15:0] Y little endian > > > + * index 1 = Cr plane, [15:0] Cr little endian > > > + * index 2 = Cb plane, [15:0] Cb little endian > > > + */ > > > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > + > > > /* > > > * 3 plane YCbCr > > > * index 0: Y plane, [7:0] Y > > > @@ -489,8 +539,10 @@ extern "C" { > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > > > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > /* add more to the end as needed */ > > > > > > @@ -772,6 +824,31 @@ extern "C" { > > > */ > > > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > > > > > +/* > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > + * on integrated graphics > > > + * > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > + * CCS data for all compressible GEM objects. > > > + */ > > > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > > > + > > > +/* > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > + * on discrete graphics > > > + * > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > + * CCS data for all compressible GEM objects. The GEM object must be stored in > > > + * contiguous memory with a size aligned to 64KB > > > + */ > > > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > > > + > > > /* > > > * IPU3 Bayer packing layout > > > * > > > @@ -780,7 +857,7 @@ extern "C" { > > > * the 6 most significant bits in the last byte unused. The format is little > > > * endian. > > > */ > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > /* > > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > > @@ -978,14 +1055,20 @@ extern "C" { > > > * 2 = Gob Height 8, Turing+ Page Kind mapping > > > * 3 = Reserved for future use. > > > * > > > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > > > - * bit remapping step that occurs at an even lower level than the > > > - * page kind and block linear swizzles. This causes the layout of > > > - * surfaces mapped in those SOC's GPUs to be incompatible with the > > > - * equivalent mapping on other GPUs in the same system. > > > - * > > > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > > > - * 1 = Desktop GPU and Tegra Xavier+ Layout > > > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > > > + * 26:27 at an even lower level than the page kind and block linear > > > + * swizzles. This causes the bit arrangement of surfaces in memory > > > + * to differ subtly, and prevents direct sharing of surfaces between > > > + * GPUs with different layouts. > > > + * > > > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > > > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > > > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > > > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > > > + * 4 = Reserved for future use. > > > + * 5 = Reserved for future use. > > > + * 6 = Reserved for future use. > > > + * 7 = Reserved for future use. > > > * > > > * 25:23 c Lossless Framebuffer Compression type. > > > * > > > @@ -1000,7 +1083,7 @@ extern "C" { > > > * 6 = Reserved for future use > > > * 7 = Reserved for future use > > > * > > > - * 55:25 - Reserved for future use. Must be zero. > > > + * 55:28 - Reserved for future use. Must be zero. > > > */ > > > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > > > fourcc_mod_code(NVIDIA, (0x10 | \ > > > @@ -1008,6 +1091,7 @@ extern "C" { > > > (((k) & 0xff) << 12) | \ > > > (((g) & 0x3) << 20) | \ > > > (((s) & 0x1) << 22) | \ > > > + (((s) & 0x6) << 25) | \ > > > (((c) & 0x7) << 23))) > > > > > > /* To grandfather in prior block linear format modifiers to the above layout, > > > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > */ > > > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > > > > > +/* MediaTek modifiers > > > + * Bits Parameter Notes > > > + * ----- ------------------------ --------------------------------------------- > > > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > > > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > > > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > > > + * > > > + */ > > > + > > > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > > > + > > > +/* > > > + * MediaTek Tiled Modifier > > > + * The lowest 8 bits of the modifier is used to specify the tiling > > > + * layout. Only the 16L_32S tiling is used for now, but we define an > > > + * "untiled" version and leave room for future expansion. > > > + */ > > > +#define MTK_FMT_MOD_TILE_MASK 0xf > > > +#define MTK_FMT_MOD_TILE_NONE 0x0 > > > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > > > + > > > +/* > > > + * Bits 8-15 specify compression options > > > + */ > > > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > > > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > > > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > > > + > > > +/* > > > + * Bits 16-23 specify how the bits of 10 bit formats are > > > + * stored out in memory > > > + */ > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > > > + > > > +/* alias for the most common tiling format */ > > > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > > > + > > > +/* > > > + * Apple GPU-tiled layouts. > > > + * > > > + * Apple GPUs support nonlinear tilings with optional lossless compression. > > > + * > > > + * GPU-tiled images are divided into 16KiB tiles: > > > + * > > > + * Bytes per pixel Tile size > > > + * --------------- --------- > > > + * 1 128x128 > > > + * 2 128x64 > > > + * 4 64x64 > > > + * 8 64x32 > > > + * 16 32x32 > > > + * > > > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > > > + * > > > + * Compressed images pad the body to 128-bytes and are immediately followed by a > > > + * metadata section. The metadata section rounds the image dimensions to > > > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > > > + * Subtiles are interleaved (Morton order). > > > + * > > > + * All images are 128-byte aligned. > > > + * > > > + * These layouts fundamentally do not have meaningful strides. No matter how we > > > + * specify strides for these layouts, userspace unaware of Apple image layouts > > > + * will be unable to use correctly the specified stride for any purpose. > > > + * Userspace aware of the image layouts do not use strides. The most "correct" > > > + * convention would be setting the image stride to 0. Unfortunately, some > > > + * software assumes the stride is at least (width * bytes per pixel). We > > > + * therefore require that stride equals (width * bytes per pixel). Since the > > > + * stride is arbitrary here, we pick the simplest convention. > > > + * > > > + * Although containing two sections, compressed image layouts are treated in > > > + * software as a single plane. This is modelled after AFBC, a similar > > > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > > > + * only generate more confusion, as software does not treat the image this way. > > > + * > > > + * For detailed information on the hardware image layouts, see > > > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > > > + */ > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > > > + > > > /* > > > * AMD modifiers > > > * > > > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > > > */ > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > > > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > > > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > > > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27 > > -- > Regards, > > Laurent Pinchart
On Tue, Dec 09, 2025 at 12:17:01PM +0000, Kieran Bingham wrote: > Quoting Laurent Pinchart (2025-12-09 12:06:08) > > On Tue, Dec 09, 2025 at 11:52:07AM +0000, Kieran Bingham wrote: > > > Quoting Jacopo Mondi (2025-12-04 15:54:14) > > > > Update drm_fourcc.h to Linux kernel version v6.18. > > > > > > > > As the upstream drm_fourcc.h version doesn't include formats > > > > definitions for RAW Bayer formats, we have to re-define some of > > > > the symbols we kept downstream as new symbols have been added in > > > > mainline with the same values. > > > > > > > > In particular: > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > and > > > > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > Are these just our 'local' references to them ? I don't think we're > > > actually using them in a kernel interface are we ? > > > > > > In which case can we put them in private numerical namespace so they > > > don't have to be re-chosen every update? > > > > The value of the macros are part of the ABI I'm afraid, see the > > generated include/libcamera/formats.h file. We'll need to upstream > > Yes, libcamera ABI - but not /kernel/ ABI - there's no kernel side to > these numbers in use right now right? > > This is just how we're representing values in libcamera... Yes that's correct, those values are not used in the kernel (at the moment). > Or do we have to align this with the Raspberry Pi BSP for instance? > > > modifiers where they make sense, but we never reached a conclusion on > > whether or not bayer formats should be upstreamed in DRM or if they > > should use a generic format with the bayer pattern being conveyed > > out-of-band. Given that V4L2 is moving in that direction, it would make > > sense to do so in the libcamera API too in my opinion. We would still > > need the modifier to indicate compression though. > > if we use 'the next available number' then this ABI break will happen on > every update. > > If we use some 'higher/private' value - then we don't have to change it > when new values are added to drm_fourcc.h on the assumption that getting > any upstream solution here will take N^2 releases. > > Yes, of course we would have to change these again when we finally do > get somethign upstream - but my question about using some private > numbers is so that we can avoid changing them every 8 weeks/every > rebase. I'd recommend keeping the values as they are today, despite the clash, and updating them (and breaking the libcamera ABI) when we upstream them. That will avoid an ABI change today. > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > > > --- > > > > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > > > > 1 file changed, 182 insertions(+), 13 deletions(-) > > > > > > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > > > > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > > > > --- a/include/linux/drm_fourcc.h > > > > +++ b/include/linux/drm_fourcc.h > > > > @@ -222,7 +222,7 @@ extern "C" { > > > > #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 > > > > + * Half-Floating point - 16b/component > > > > * IEEE 754-2008 binary16 half-precision float > > > > * [15:0] sign:exponent:mantissa 1:5:10 > > > > */ > > > > @@ -232,6 +232,20 @@ 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 */ > > > > > > > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > > > > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > > > > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > > > > + > > > > +/* > > > > + * Floating point - 32b/component > > > > + * IEEE 754-2008 binary32 float > > > > + * [31:0] sign:exponent:mantissa 1:8:23 > > > > + */ > > > > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > > > > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > > > > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > > > > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > > > > + > > > > /* > > > > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > > > > * of unused padding per component: > > > > @@ -381,6 +395,42 @@ extern "C" { > > > > */ > > > > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > > > > > > > +/* > > > > + * 3 plane YCbCr LSB aligned > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > + * implementation can multiply the values by 2^6=64. For that reason the padding > > > > + * must only contain zeros. > > > > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > > > > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > > > > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > > > > + */ > > > > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > + > > > > +/* > > > > + * 3 plane YCbCr LSB aligned > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > + * implementation can multiply the values by 2^4=16. For that reason the padding > > > > + * must only contain zeros. > > > > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > > > > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > > > > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > > > > + */ > > > > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > + > > > > +/* > > > > + * 3 plane YCbCr > > > > + * index 0 = Y plane, [15:0] Y little endian > > > > + * index 1 = Cr plane, [15:0] Cr little endian > > > > + * index 2 = Cb plane, [15:0] Cb little endian > > > > + */ > > > > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > + > > > > /* > > > > * 3 plane YCbCr > > > > * index 0: Y plane, [7:0] Y > > > > @@ -489,8 +539,10 @@ extern "C" { > > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > > > > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > > > /* add more to the end as needed */ > > > > > > > > @@ -772,6 +824,31 @@ extern "C" { > > > > */ > > > > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > > > > > > > +/* > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > + * on integrated graphics > > > > + * > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > + * CCS data for all compressible GEM objects. > > > > + */ > > > > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > > > > + > > > > +/* > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > + * on discrete graphics > > > > + * > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > + * CCS data for all compressible GEM objects. The GEM object must be stored in > > > > + * contiguous memory with a size aligned to 64KB > > > > + */ > > > > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > > > > + > > > > /* > > > > * IPU3 Bayer packing layout > > > > * > > > > @@ -780,7 +857,7 @@ extern "C" { > > > > * the 6 most significant bits in the last byte unused. The format is little > > > > * endian. > > > > */ > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > /* > > > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > > > @@ -978,14 +1055,20 @@ extern "C" { > > > > * 2 = Gob Height 8, Turing+ Page Kind mapping > > > > * 3 = Reserved for future use. > > > > * > > > > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > > > > - * bit remapping step that occurs at an even lower level than the > > > > - * page kind and block linear swizzles. This causes the layout of > > > > - * surfaces mapped in those SOC's GPUs to be incompatible with the > > > > - * equivalent mapping on other GPUs in the same system. > > > > - * > > > > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > > > > - * 1 = Desktop GPU and Tegra Xavier+ Layout > > > > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > > > > + * 26:27 at an even lower level than the page kind and block linear > > > > + * swizzles. This causes the bit arrangement of surfaces in memory > > > > + * to differ subtly, and prevents direct sharing of surfaces between > > > > + * GPUs with different layouts. > > > > + * > > > > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > > > > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > > > > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > > > > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > > > > + * 4 = Reserved for future use. > > > > + * 5 = Reserved for future use. > > > > + * 6 = Reserved for future use. > > > > + * 7 = Reserved for future use. > > > > * > > > > * 25:23 c Lossless Framebuffer Compression type. > > > > * > > > > @@ -1000,7 +1083,7 @@ extern "C" { > > > > * 6 = Reserved for future use > > > > * 7 = Reserved for future use > > > > * > > > > - * 55:25 - Reserved for future use. Must be zero. > > > > + * 55:28 - Reserved for future use. Must be zero. > > > > */ > > > > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > > > > fourcc_mod_code(NVIDIA, (0x10 | \ > > > > @@ -1008,6 +1091,7 @@ extern "C" { > > > > (((k) & 0xff) << 12) | \ > > > > (((g) & 0x3) << 20) | \ > > > > (((s) & 0x1) << 22) | \ > > > > + (((s) & 0x6) << 25) | \ > > > > (((c) & 0x7) << 23))) > > > > > > > > /* To grandfather in prior block linear format modifiers to the above layout, > > > > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > */ > > > > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > > > > > > > +/* MediaTek modifiers > > > > + * Bits Parameter Notes > > > > + * ----- ------------------------ --------------------------------------------- > > > > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > > > > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > > > > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > > > > + * > > > > + */ > > > > + > > > > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > > > > + > > > > +/* > > > > + * MediaTek Tiled Modifier > > > > + * The lowest 8 bits of the modifier is used to specify the tiling > > > > + * layout. Only the 16L_32S tiling is used for now, but we define an > > > > + * "untiled" version and leave room for future expansion. > > > > + */ > > > > +#define MTK_FMT_MOD_TILE_MASK 0xf > > > > +#define MTK_FMT_MOD_TILE_NONE 0x0 > > > > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > > > > + > > > > +/* > > > > + * Bits 8-15 specify compression options > > > > + */ > > > > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > > > > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > > > > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > > > > + > > > > +/* > > > > + * Bits 16-23 specify how the bits of 10 bit formats are > > > > + * stored out in memory > > > > + */ > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > > > > + > > > > +/* alias for the most common tiling format */ > > > > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > > > > + > > > > +/* > > > > + * Apple GPU-tiled layouts. > > > > + * > > > > + * Apple GPUs support nonlinear tilings with optional lossless compression. > > > > + * > > > > + * GPU-tiled images are divided into 16KiB tiles: > > > > + * > > > > + * Bytes per pixel Tile size > > > > + * --------------- --------- > > > > + * 1 128x128 > > > > + * 2 128x64 > > > > + * 4 64x64 > > > > + * 8 64x32 > > > > + * 16 32x32 > > > > + * > > > > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > > > > + * > > > > + * Compressed images pad the body to 128-bytes and are immediately followed by a > > > > + * metadata section. The metadata section rounds the image dimensions to > > > > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > > > > + * Subtiles are interleaved (Morton order). > > > > + * > > > > + * All images are 128-byte aligned. > > > > + * > > > > + * These layouts fundamentally do not have meaningful strides. No matter how we > > > > + * specify strides for these layouts, userspace unaware of Apple image layouts > > > > + * will be unable to use correctly the specified stride for any purpose. > > > > + * Userspace aware of the image layouts do not use strides. The most "correct" > > > > + * convention would be setting the image stride to 0. Unfortunately, some > > > > + * software assumes the stride is at least (width * bytes per pixel). We > > > > + * therefore require that stride equals (width * bytes per pixel). Since the > > > > + * stride is arbitrary here, we pick the simplest convention. > > > > + * > > > > + * Although containing two sections, compressed image layouts are treated in > > > > + * software as a single plane. This is modelled after AFBC, a similar > > > > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > > > > + * only generate more confusion, as software does not treat the image this way. > > > > + * > > > > + * For detailed information on the hardware image layouts, see > > > > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > > > > + */ > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > > > > + > > > > /* > > > > * AMD modifiers > > > > * > > > > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > > > > */ > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > > > > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27
Quoting Laurent Pinchart (2025-12-09 12:25:36) > On Tue, Dec 09, 2025 at 12:17:01PM +0000, Kieran Bingham wrote: > > Quoting Laurent Pinchart (2025-12-09 12:06:08) > > > On Tue, Dec 09, 2025 at 11:52:07AM +0000, Kieran Bingham wrote: > > > > Quoting Jacopo Mondi (2025-12-04 15:54:14) > > > > > Update drm_fourcc.h to Linux kernel version v6.18. > > > > > > > > > > As the upstream drm_fourcc.h version doesn't include formats > > > > > definitions for RAW Bayer formats, we have to re-define some of > > > > > the symbols we kept downstream as new symbols have been added in > > > > > mainline with the same values. > > > > > > > > > > In particular: > > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > > > and > > > > > > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > > > Are these just our 'local' references to them ? I don't think we're > > > > actually using them in a kernel interface are we ? > > > > > > > > In which case can we put them in private numerical namespace so they > > > > don't have to be re-chosen every update? > > > > > > The value of the macros are part of the ABI I'm afraid, see the > > > generated include/libcamera/formats.h file. We'll need to upstream > > > > Yes, libcamera ABI - but not /kernel/ ABI - there's no kernel side to > > these numbers in use right now right? > > > > This is just how we're representing values in libcamera... > > Yes that's correct, those values are not used in the kernel (at the > moment). > > > Or do we have to align this with the Raspberry Pi BSP for instance? > > > > > modifiers where they make sense, but we never reached a conclusion on > > > whether or not bayer formats should be upstreamed in DRM or if they > > > should use a generic format with the bayer pattern being conveyed > > > out-of-band. Given that V4L2 is moving in that direction, it would make > > > sense to do so in the libcamera API too in my opinion. We would still > > > need the modifier to indicate compression though. > > > > if we use 'the next available number' then this ABI break will happen on > > every update. > > > > If we use some 'higher/private' value - then we don't have to change it > > when new values are added to drm_fourcc.h on the assumption that getting > > any upstream solution here will take N^2 releases. > > > > Yes, of course we would have to change these again when we finally do > > get somethign upstream - but my question about using some private > > numbers is so that we can avoid changing them every 8 weeks/every > > rebase. > > I'd recommend keeping the values as they are today, despite the clash, > and updating them (and breaking the libcamera ABI) when we upstream > them. That will avoid an ABI change today. I'm fine with that too - I don't think the clash will have any material impact on the usage for us and will prevent ABI breakage. -- Kieran > > > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > > > > --- > > > > > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > > > > > 1 file changed, 182 insertions(+), 13 deletions(-) > > > > > > > > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > > > > > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > > > > > --- a/include/linux/drm_fourcc.h > > > > > +++ b/include/linux/drm_fourcc.h > > > > > @@ -222,7 +222,7 @@ extern "C" { > > > > > #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 > > > > > + * Half-Floating point - 16b/component > > > > > * IEEE 754-2008 binary16 half-precision float > > > > > * [15:0] sign:exponent:mantissa 1:5:10 > > > > > */ > > > > > @@ -232,6 +232,20 @@ 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 */ > > > > > > > > > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > > > > > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > > > > > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > > > > > + > > > > > +/* > > > > > + * Floating point - 32b/component > > > > > + * IEEE 754-2008 binary32 float > > > > > + * [31:0] sign:exponent:mantissa 1:8:23 > > > > > + */ > > > > > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > > > > > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > > > > > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > > > > > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > > > > > + > > > > > /* > > > > > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > > > > > * of unused padding per component: > > > > > @@ -381,6 +395,42 @@ extern "C" { > > > > > */ > > > > > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > > > > > > > > > +/* > > > > > + * 3 plane YCbCr LSB aligned > > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > > + * implementation can multiply the values by 2^6=64. For that reason the padding > > > > > + * must only contain zeros. > > > > > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > > > > > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > > > > > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > > > > > + */ > > > > > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > + > > > > > +/* > > > > > + * 3 plane YCbCr LSB aligned > > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > > + * implementation can multiply the values by 2^4=16. For that reason the padding > > > > > + * must only contain zeros. > > > > > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > > > > > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > > > > > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > > > > > + */ > > > > > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > + > > > > > +/* > > > > > + * 3 plane YCbCr > > > > > + * index 0 = Y plane, [15:0] Y little endian > > > > > + * index 1 = Cr plane, [15:0] Cr little endian > > > > > + * index 2 = Cb plane, [15:0] Cb little endian > > > > > + */ > > > > > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > + > > > > > /* > > > > > * 3 plane YCbCr > > > > > * index 0: Y plane, [7:0] Y > > > > > @@ -489,8 +539,10 @@ extern "C" { > > > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > > > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > > > > > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > > > > > /* add more to the end as needed */ > > > > > > > > > > @@ -772,6 +824,31 @@ extern "C" { > > > > > */ > > > > > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > > > > > > > > > +/* > > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > > + * on integrated graphics > > > > > + * > > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > > + * CCS data for all compressible GEM objects. > > > > > + */ > > > > > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > > > > > + > > > > > +/* > > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > > + * on discrete graphics > > > > > + * > > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > > + * CCS data for all compressible GEM objects. The GEM object must be stored in > > > > > + * contiguous memory with a size aligned to 64KB > > > > > + */ > > > > > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > > > > > + > > > > > /* > > > > > * IPU3 Bayer packing layout > > > > > * > > > > > @@ -780,7 +857,7 @@ extern "C" { > > > > > * the 6 most significant bits in the last byte unused. The format is little > > > > > * endian. > > > > > */ > > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > > > /* > > > > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > > > > @@ -978,14 +1055,20 @@ extern "C" { > > > > > * 2 = Gob Height 8, Turing+ Page Kind mapping > > > > > * 3 = Reserved for future use. > > > > > * > > > > > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > > > > > - * bit remapping step that occurs at an even lower level than the > > > > > - * page kind and block linear swizzles. This causes the layout of > > > > > - * surfaces mapped in those SOC's GPUs to be incompatible with the > > > > > - * equivalent mapping on other GPUs in the same system. > > > > > - * > > > > > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > > > > > - * 1 = Desktop GPU and Tegra Xavier+ Layout > > > > > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > > > > > + * 26:27 at an even lower level than the page kind and block linear > > > > > + * swizzles. This causes the bit arrangement of surfaces in memory > > > > > + * to differ subtly, and prevents direct sharing of surfaces between > > > > > + * GPUs with different layouts. > > > > > + * > > > > > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > > > > > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > > > > > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > > > > > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > > > > > + * 4 = Reserved for future use. > > > > > + * 5 = Reserved for future use. > > > > > + * 6 = Reserved for future use. > > > > > + * 7 = Reserved for future use. > > > > > * > > > > > * 25:23 c Lossless Framebuffer Compression type. > > > > > * > > > > > @@ -1000,7 +1083,7 @@ extern "C" { > > > > > * 6 = Reserved for future use > > > > > * 7 = Reserved for future use > > > > > * > > > > > - * 55:25 - Reserved for future use. Must be zero. > > > > > + * 55:28 - Reserved for future use. Must be zero. > > > > > */ > > > > > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > > > > > fourcc_mod_code(NVIDIA, (0x10 | \ > > > > > @@ -1008,6 +1091,7 @@ extern "C" { > > > > > (((k) & 0xff) << 12) | \ > > > > > (((g) & 0x3) << 20) | \ > > > > > (((s) & 0x1) << 22) | \ > > > > > + (((s) & 0x6) << 25) | \ > > > > > (((c) & 0x7) << 23))) > > > > > > > > > > /* To grandfather in prior block linear format modifiers to the above layout, > > > > > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > > */ > > > > > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > > > > > > > > > +/* MediaTek modifiers > > > > > + * Bits Parameter Notes > > > > > + * ----- ------------------------ --------------------------------------------- > > > > > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > > > > > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > > > > > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > > > > > + * > > > > > + */ > > > > > + > > > > > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > > > > > + > > > > > +/* > > > > > + * MediaTek Tiled Modifier > > > > > + * The lowest 8 bits of the modifier is used to specify the tiling > > > > > + * layout. Only the 16L_32S tiling is used for now, but we define an > > > > > + * "untiled" version and leave room for future expansion. > > > > > + */ > > > > > +#define MTK_FMT_MOD_TILE_MASK 0xf > > > > > +#define MTK_FMT_MOD_TILE_NONE 0x0 > > > > > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > > > > > + > > > > > +/* > > > > > + * Bits 8-15 specify compression options > > > > > + */ > > > > > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > > > > > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > > > > > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > > > > > + > > > > > +/* > > > > > + * Bits 16-23 specify how the bits of 10 bit formats are > > > > > + * stored out in memory > > > > > + */ > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > > > > > + > > > > > +/* alias for the most common tiling format */ > > > > > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > > > > > + > > > > > +/* > > > > > + * Apple GPU-tiled layouts. > > > > > + * > > > > > + * Apple GPUs support nonlinear tilings with optional lossless compression. > > > > > + * > > > > > + * GPU-tiled images are divided into 16KiB tiles: > > > > > + * > > > > > + * Bytes per pixel Tile size > > > > > + * --------------- --------- > > > > > + * 1 128x128 > > > > > + * 2 128x64 > > > > > + * 4 64x64 > > > > > + * 8 64x32 > > > > > + * 16 32x32 > > > > > + * > > > > > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > > > > > + * > > > > > + * Compressed images pad the body to 128-bytes and are immediately followed by a > > > > > + * metadata section. The metadata section rounds the image dimensions to > > > > > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > > > > > + * Subtiles are interleaved (Morton order). > > > > > + * > > > > > + * All images are 128-byte aligned. > > > > > + * > > > > > + * These layouts fundamentally do not have meaningful strides. No matter how we > > > > > + * specify strides for these layouts, userspace unaware of Apple image layouts > > > > > + * will be unable to use correctly the specified stride for any purpose. > > > > > + * Userspace aware of the image layouts do not use strides. The most "correct" > > > > > + * convention would be setting the image stride to 0. Unfortunately, some > > > > > + * software assumes the stride is at least (width * bytes per pixel). We > > > > > + * therefore require that stride equals (width * bytes per pixel). Since the > > > > > + * stride is arbitrary here, we pick the simplest convention. > > > > > + * > > > > > + * Although containing two sections, compressed image layouts are treated in > > > > > + * software as a single plane. This is modelled after AFBC, a similar > > > > > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > > > > > + * only generate more confusion, as software does not treat the image this way. > > > > > + * > > > > > + * For detailed information on the hardware image layouts, see > > > > > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > > > > > + */ > > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > > > > > + > > > > > /* > > > > > * AMD modifiers > > > > > * > > > > > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > > > > > */ > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > > > > > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27 > > -- > Regards, > > Laurent Pinchart
Hello On Tue, Dec 09, 2025 at 12:41:11PM +0000, Kieran Bingham wrote: > Quoting Laurent Pinchart (2025-12-09 12:25:36) > > On Tue, Dec 09, 2025 at 12:17:01PM +0000, Kieran Bingham wrote: > > > Quoting Laurent Pinchart (2025-12-09 12:06:08) > > > > On Tue, Dec 09, 2025 at 11:52:07AM +0000, Kieran Bingham wrote: > > > > > Quoting Jacopo Mondi (2025-12-04 15:54:14) > > > > > > Update drm_fourcc.h to Linux kernel version v6.18. > > > > > > > > > > > > As the upstream drm_fourcc.h version doesn't include formats > > > > > > definitions for RAW Bayer formats, we have to re-define some of > > > > > > the symbols we kept downstream as new symbols have been added in > > > > > > mainline with the same values. > > > > > > > > > > > > In particular: > > > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > > > > > and > > > > > > > > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > > > > > Are these just our 'local' references to them ? I don't think we're > > > > > actually using them in a kernel interface are we ? > > > > > > > > > > In which case can we put them in private numerical namespace so they > > > > > don't have to be re-chosen every update? > > > > > > > > The value of the macros are part of the ABI I'm afraid, see the > > > > generated include/libcamera/formats.h file. We'll need to upstream > > > > > > Yes, libcamera ABI - but not /kernel/ ABI - there's no kernel side to > > > these numbers in use right now right? > > > > > > This is just how we're representing values in libcamera... > > > > Yes that's correct, those values are not used in the kernel (at the > > moment). > > > > > Or do we have to align this with the Raspberry Pi BSP for instance? > > > > > > > modifiers where they make sense, but we never reached a conclusion on > > > > whether or not bayer formats should be upstreamed in DRM or if they > > > > should use a generic format with the bayer pattern being conveyed > > > > out-of-band. Given that V4L2 is moving in that direction, it would make > > > > sense to do so in the libcamera API too in my opinion. We would still > > > > need the modifier to indicate compression though. > > > > > > if we use 'the next available number' then this ABI break will happen on > > > every update. > > > > > > If we use some 'higher/private' value - then we don't have to change it > > > when new values are added to drm_fourcc.h on the assumption that getting > > > any upstream solution here will take N^2 releases. > > > > > > Yes, of course we would have to change these again when we finally do > > > get somethign upstream - but my question about using some private > > > numbers is so that we can avoid changing them every 8 weeks/every > > > rebase. > > > > I'd recommend keeping the values as they are today, despite the clash, > > and updating them (and breaking the libcamera ABI) when we upstream > > them. That will avoid an ABI change today. > > I'm fine with that too - I don't think the clash will have any material > impact on the usage for us and will prevent ABI breakage. > Am I right in my understanding that we're fine with our downstream symbols: #define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b #define DRM_FORMAT_MOD_VENDOR_RPI 0x0c conflicting with the newly added symbols in mainline: #define DRM_FORMAT_MOD_VENDOR_MTK 0x0b #define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c ? > -- > Kieran > > > > > > > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > > > > > --- > > > > > > include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- > > > > > > 1 file changed, 182 insertions(+), 13 deletions(-) > > > > > > > > > > > > diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h > > > > > > index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 > > > > > > --- a/include/linux/drm_fourcc.h > > > > > > +++ b/include/linux/drm_fourcc.h > > > > > > @@ -222,7 +222,7 @@ extern "C" { > > > > > > #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 > > > > > > + * Half-Floating point - 16b/component > > > > > > * IEEE 754-2008 binary16 half-precision float > > > > > > * [15:0] sign:exponent:mantissa 1:5:10 > > > > > > */ > > > > > > @@ -232,6 +232,20 @@ 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 */ > > > > > > > > > > > > +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ > > > > > > +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ > > > > > > +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ > > > > > > + > > > > > > +/* > > > > > > + * Floating point - 32b/component > > > > > > + * IEEE 754-2008 binary32 float > > > > > > + * [31:0] sign:exponent:mantissa 1:8:23 > > > > > > + */ > > > > > > +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ > > > > > > +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ > > > > > > +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ > > > > > > +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ > > > > > > + > > > > > > /* > > > > > > * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits > > > > > > * of unused padding per component: > > > > > > @@ -381,6 +395,42 @@ extern "C" { > > > > > > */ > > > > > > #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') > > > > > > > > > > > > +/* > > > > > > + * 3 plane YCbCr LSB aligned > > > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > > > + * implementation can multiply the values by 2^6=64. For that reason the padding > > > > > > + * must only contain zeros. > > > > > > + * index 0 = Y plane, [15:0] z:Y [6:10] little endian > > > > > > + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian > > > > > > + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian > > > > > > + */ > > > > > > +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > > +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > > +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ > > > > > > + > > > > > > +/* > > > > > > + * 3 plane YCbCr LSB aligned > > > > > > + * In order to use these formats in a similar fashion to MSB aligned ones > > > > > > + * implementation can multiply the values by 2^4=16. For that reason the padding > > > > > > + * must only contain zeros. > > > > > > + * index 0 = Y plane, [15:0] z:Y [4:12] little endian > > > > > > + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian > > > > > > + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian > > > > > > + */ > > > > > > +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > > +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > > +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ > > > > > > + > > > > > > +/* > > > > > > + * 3 plane YCbCr > > > > > > + * index 0 = Y plane, [15:0] Y little endian > > > > > > + * index 1 = Cr plane, [15:0] Cr little endian > > > > > > + * index 2 = Cb plane, [15:0] Cb little endian > > > > > > + */ > > > > > > +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > > +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > > +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ > > > > > > + > > > > > > /* > > > > > > * 3 plane YCbCr > > > > > > * index 0: Y plane, [7:0] Y > > > > > > @@ -489,8 +539,10 @@ extern "C" { > > > > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > > > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > > > > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > > > > > -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b > > > > > > -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c > > > > > > +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b > > > > > > +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c > > > > > > +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e > > > > > > +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f > > > > > > > > > > > > /* add more to the end as needed */ > > > > > > > > > > > > @@ -772,6 +824,31 @@ extern "C" { > > > > > > */ > > > > > > #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) > > > > > > > > > > > > +/* > > > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > > > + * on integrated graphics > > > > > > + * > > > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > > > + * CCS data for all compressible GEM objects. > > > > > > + */ > > > > > > +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) > > > > > > + > > > > > > +/* > > > > > > + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression > > > > > > + * on discrete graphics > > > > > > + * > > > > > > + * The main surface is Tile 4 and at plane index 0. For semi-planar formats > > > > > > + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices > > > > > > + * 0 and 1, respectively. The CCS for all planes are stored outside of the > > > > > > + * GEM object in a reserved memory area dedicated for the storage of the > > > > > > + * CCS data for all compressible GEM objects. The GEM object must be stored in > > > > > > + * contiguous memory with a size aligned to 64KB > > > > > > + */ > > > > > > +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) > > > > > > + > > > > > > /* > > > > > > * IPU3 Bayer packing layout > > > > > > * > > > > > > @@ -780,7 +857,7 @@ extern "C" { > > > > > > * the 6 most significant bits in the last byte unused. The format is little > > > > > > * endian. > > > > > > */ > > > > > > -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) > > > > > > +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) > > > > > > > > > > > > /* > > > > > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > > > > > @@ -978,14 +1055,20 @@ extern "C" { > > > > > > * 2 = Gob Height 8, Turing+ Page Kind mapping > > > > > > * 3 = Reserved for future use. > > > > > > * > > > > > > - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further > > > > > > - * bit remapping step that occurs at an even lower level than the > > > > > > - * page kind and block linear swizzles. This causes the layout of > > > > > > - * surfaces mapped in those SOC's GPUs to be incompatible with the > > > > > > - * equivalent mapping on other GPUs in the same system. > > > > > > - * > > > > > > - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. > > > > > > - * 1 = Desktop GPU and Tegra Xavier+ Layout > > > > > > + * 22:22 s Sector layout. There is a further bit remapping step that occurs > > > > > > + * 26:27 at an even lower level than the page kind and block linear > > > > > > + * swizzles. This causes the bit arrangement of surfaces in memory > > > > > > + * to differ subtly, and prevents direct sharing of surfaces between > > > > > > + * GPUs with different layouts. > > > > > > + * > > > > > > + * 0 = Tegra K1 - Tegra Parker/TX2 Layout > > > > > > + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout > > > > > > + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout > > > > > > + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout > > > > > > + * 4 = Reserved for future use. > > > > > > + * 5 = Reserved for future use. > > > > > > + * 6 = Reserved for future use. > > > > > > + * 7 = Reserved for future use. > > > > > > * > > > > > > * 25:23 c Lossless Framebuffer Compression type. > > > > > > * > > > > > > @@ -1000,7 +1083,7 @@ extern "C" { > > > > > > * 6 = Reserved for future use > > > > > > * 7 = Reserved for future use > > > > > > * > > > > > > - * 55:25 - Reserved for future use. Must be zero. > > > > > > + * 55:28 - Reserved for future use. Must be zero. > > > > > > */ > > > > > > #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ > > > > > > fourcc_mod_code(NVIDIA, (0x10 | \ > > > > > > @@ -1008,6 +1091,7 @@ extern "C" { > > > > > > (((k) & 0xff) << 12) | \ > > > > > > (((g) & 0x3) << 20) | \ > > > > > > (((s) & 0x1) << 22) | \ > > > > > > + (((s) & 0x6) << 25) | \ > > > > > > (((c) & 0x7) << 23))) > > > > > > > > > > > > /* To grandfather in prior block linear format modifiers to the above layout, > > > > > > @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > > > */ > > > > > > #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) > > > > > > > > > > > > +/* MediaTek modifiers > > > > > > + * Bits Parameter Notes > > > > > > + * ----- ------------------------ --------------------------------------------- > > > > > > + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* > > > > > > + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* > > > > > > + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* > > > > > > + * > > > > > > + */ > > > > > > + > > > > > > +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) > > > > > > + > > > > > > +/* > > > > > > + * MediaTek Tiled Modifier > > > > > > + * The lowest 8 bits of the modifier is used to specify the tiling > > > > > > + * layout. Only the 16L_32S tiling is used for now, but we define an > > > > > > + * "untiled" version and leave room for future expansion. > > > > > > + */ > > > > > > +#define MTK_FMT_MOD_TILE_MASK 0xf > > > > > > +#define MTK_FMT_MOD_TILE_NONE 0x0 > > > > > > +#define MTK_FMT_MOD_TILE_16L32S 0x1 > > > > > > + > > > > > > +/* > > > > > > + * Bits 8-15 specify compression options > > > > > > + */ > > > > > > +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) > > > > > > +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) > > > > > > +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) > > > > > > + > > > > > > +/* > > > > > > + * Bits 16-23 specify how the bits of 10 bit formats are > > > > > > + * stored out in memory > > > > > > + */ > > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) > > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) > > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) > > > > > > +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) > > > > > > + > > > > > > +/* alias for the most common tiling format */ > > > > > > +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) > > > > > > + > > > > > > +/* > > > > > > + * Apple GPU-tiled layouts. > > > > > > + * > > > > > > + * Apple GPUs support nonlinear tilings with optional lossless compression. > > > > > > + * > > > > > > + * GPU-tiled images are divided into 16KiB tiles: > > > > > > + * > > > > > > + * Bytes per pixel Tile size > > > > > > + * --------------- --------- > > > > > > + * 1 128x128 > > > > > > + * 2 128x64 > > > > > > + * 4 64x64 > > > > > > + * 8 64x32 > > > > > > + * 16 32x32 > > > > > > + * > > > > > > + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). > > > > > > + * > > > > > > + * Compressed images pad the body to 128-bytes and are immediately followed by a > > > > > > + * metadata section. The metadata section rounds the image dimensions to > > > > > > + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. > > > > > > + * Subtiles are interleaved (Morton order). > > > > > > + * > > > > > > + * All images are 128-byte aligned. > > > > > > + * > > > > > > + * These layouts fundamentally do not have meaningful strides. No matter how we > > > > > > + * specify strides for these layouts, userspace unaware of Apple image layouts > > > > > > + * will be unable to use correctly the specified stride for any purpose. > > > > > > + * Userspace aware of the image layouts do not use strides. The most "correct" > > > > > > + * convention would be setting the image stride to 0. Unfortunately, some > > > > > > + * software assumes the stride is at least (width * bytes per pixel). We > > > > > > + * therefore require that stride equals (width * bytes per pixel). Since the > > > > > > + * stride is arbitrary here, we pick the simplest convention. > > > > > > + * > > > > > > + * Although containing two sections, compressed image layouts are treated in > > > > > > + * software as a single plane. This is modelled after AFBC, a similar > > > > > > + * scheme. Attempting to separate the sections to be "explicit" in DRM would > > > > > > + * only generate more confusion, as software does not treat the image this way. > > > > > > + * > > > > > > + * For detailed information on the hardware image layouts, see > > > > > > + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts > > > > > > + */ > > > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) > > > > > > +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) > > > > > > + > > > > > > /* > > > > > > * AMD modifiers > > > > > > * > > > > > > @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > > > > > * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. > > > > > > */ > > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 > > > > > > +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 > > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 > > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 > > > > > > #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27 > > > > -- > > Regards, > > > > Laurent Pinchart
diff --git a/include/linux/drm_fourcc.h b/include/linux/drm_fourcc.h index db6798776663086c12d321d2ed708edc7ec77f71..26e2cdddc9625ec494d0c8f944f87d6439c3588d 100644 --- a/include/linux/drm_fourcc.h +++ b/include/linux/drm_fourcc.h @@ -222,7 +222,7 @@ extern "C" { #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 + * Half-Floating point - 16b/component * IEEE 754-2008 binary16 half-precision float * [15:0] sign:exponent:mantissa 1:5:10 */ @@ -232,6 +232,20 @@ 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 */ +#define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H') /* [15:0] R 16 little endian */ +#define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H') /* [31:0] G:R 16:16 little endian */ +#define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H') /* [47:0] B:G:R 16:16:16 little endian */ + +/* + * Floating point - 32b/component + * IEEE 754-2008 binary32 float + * [31:0] sign:exponent:mantissa 1:8:23 + */ +#define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F') /* [31:0] R 32 little endian */ +#define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F') /* [63:0] R:G 32:32 little endian */ +#define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F') /* [95:0] R:G:B 32:32:32 little endian */ +#define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F') /* [127:0] R:G:B:A 32:32:32:32 little endian */ + /* * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits * of unused padding per component: @@ -381,6 +395,42 @@ extern "C" { */ #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1') +/* + * 3 plane YCbCr LSB aligned + * In order to use these formats in a similar fashion to MSB aligned ones + * implementation can multiply the values by 2^6=64. For that reason the padding + * must only contain zeros. + * index 0 = Y plane, [15:0] z:Y [6:10] little endian + * index 1 = Cr plane, [15:0] z:Cr [6:10] little endian + * index 2 = Cb plane, [15:0] z:Cb [6:10] little endian + */ +#define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0') /* 2x2 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ +#define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0') /* 2x1 subsampled Cb (1) and Cr (2) planes 10 bits per channel */ +#define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0') /* non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */ + +/* + * 3 plane YCbCr LSB aligned + * In order to use these formats in a similar fashion to MSB aligned ones + * implementation can multiply the values by 2^4=16. For that reason the padding + * must only contain zeros. + * index 0 = Y plane, [15:0] z:Y [4:12] little endian + * index 1 = Cr plane, [15:0] z:Cr [4:12] little endian + * index 2 = Cb plane, [15:0] z:Cb [4:12] little endian + */ +#define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ +#define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2') /* 2x1 subsampled Cb (1) and Cr (2) planes 12 bits per channel */ +#define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2') /* non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */ + +/* + * 3 plane YCbCr + * index 0 = Y plane, [15:0] Y little endian + * index 1 = Cr plane, [15:0] Cr little endian + * index 2 = Cb plane, [15:0] Cb little endian + */ +#define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6') /* 2x2 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ +#define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6') /* 2x1 subsampled Cb (1) and Cr (2) planes 16 bits per channel */ +#define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6') /* non-subsampled Cb (1) and Cr (2) planes 16 bits per channel */ + /* * 3 plane YCbCr * index 0: Y plane, [7:0] Y @@ -489,8 +539,10 @@ extern "C" { #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c +#define DRM_FORMAT_MOD_VENDOR_MTK 0x0b +#define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f /* add more to the end as needed */ @@ -772,6 +824,31 @@ extern "C" { */ #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15) +/* + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression + * on integrated graphics + * + * The main surface is Tile 4 and at plane index 0. For semi-planar formats + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices + * 0 and 1, respectively. The CCS for all planes are stored outside of the + * GEM object in a reserved memory area dedicated for the storage of the + * CCS data for all compressible GEM objects. + */ +#define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16) + +/* + * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression + * on discrete graphics + * + * The main surface is Tile 4 and at plane index 0. For semi-planar formats + * like NV12, the Y and UV planes are Tile 4 and are located at plane indices + * 0 and 1, respectively. The CCS for all planes are stored outside of the + * GEM object in a reserved memory area dedicated for the storage of the + * CCS data for all compressible GEM objects. The GEM object must be stored in + * contiguous memory with a size aligned to 64KB + */ +#define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17) + /* * IPU3 Bayer packing layout * @@ -780,7 +857,7 @@ extern "C" { * the 6 most significant bits in the last byte unused. The format is little * endian. */ -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) /* * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks @@ -978,14 +1055,20 @@ extern "C" { * 2 = Gob Height 8, Turing+ Page Kind mapping * 3 = Reserved for future use. * - * 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further - * bit remapping step that occurs at an even lower level than the - * page kind and block linear swizzles. This causes the layout of - * surfaces mapped in those SOC's GPUs to be incompatible with the - * equivalent mapping on other GPUs in the same system. - * - * 0 = Tegra K1 - Tegra Parker/TX2 Layout. - * 1 = Desktop GPU and Tegra Xavier+ Layout + * 22:22 s Sector layout. There is a further bit remapping step that occurs + * 26:27 at an even lower level than the page kind and block linear + * swizzles. This causes the bit arrangement of surfaces in memory + * to differ subtly, and prevents direct sharing of surfaces between + * GPUs with different layouts. + * + * 0 = Tegra K1 - Tegra Parker/TX2 Layout + * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout + * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout + * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout + * 4 = Reserved for future use. + * 5 = Reserved for future use. + * 6 = Reserved for future use. + * 7 = Reserved for future use. * * 25:23 c Lossless Framebuffer Compression type. * @@ -1000,7 +1083,7 @@ extern "C" { * 6 = Reserved for future use * 7 = Reserved for future use * - * 55:25 - Reserved for future use. Must be zero. + * 55:28 - Reserved for future use. Must be zero. */ #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \ fourcc_mod_code(NVIDIA, (0x10 | \ @@ -1008,6 +1091,7 @@ extern "C" { (((k) & 0xff) << 12) | \ (((g) & 0x3) << 20) | \ (((s) & 0x1) << 22) | \ + (((s) & 0x6) << 25) | \ (((c) & 0x7) << 23))) /* To grandfather in prior block linear format modifiers to the above layout, @@ -1508,6 +1592,90 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) */ #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0) +/* MediaTek modifiers + * Bits Parameter Notes + * ----- ------------------------ --------------------------------------------- + * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_* + * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_* + * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_* + * + */ + +#define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags) + +/* + * MediaTek Tiled Modifier + * The lowest 8 bits of the modifier is used to specify the tiling + * layout. Only the 16L_32S tiling is used for now, but we define an + * "untiled" version and leave room for future expansion. + */ +#define MTK_FMT_MOD_TILE_MASK 0xf +#define MTK_FMT_MOD_TILE_NONE 0x0 +#define MTK_FMT_MOD_TILE_16L32S 0x1 + +/* + * Bits 8-15 specify compression options + */ +#define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8) +#define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8) +#define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8) + +/* + * Bits 16-23 specify how the bits of 10 bit formats are + * stored out in memory + */ +#define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16) +#define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16) +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16) +#define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16) + +/* alias for the most common tiling format */ +#define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S) + +/* + * Apple GPU-tiled layouts. + * + * Apple GPUs support nonlinear tilings with optional lossless compression. + * + * GPU-tiled images are divided into 16KiB tiles: + * + * Bytes per pixel Tile size + * --------------- --------- + * 1 128x128 + * 2 128x64 + * 4 64x64 + * 8 64x32 + * 16 32x32 + * + * Tiles are raster-order. Pixels within a tile are interleaved (Morton order). + * + * Compressed images pad the body to 128-bytes and are immediately followed by a + * metadata section. The metadata section rounds the image dimensions to + * powers-of-two and contains 8 bytes for each 16x16 compression subtile. + * Subtiles are interleaved (Morton order). + * + * All images are 128-byte aligned. + * + * These layouts fundamentally do not have meaningful strides. No matter how we + * specify strides for these layouts, userspace unaware of Apple image layouts + * will be unable to use correctly the specified stride for any purpose. + * Userspace aware of the image layouts do not use strides. The most "correct" + * convention would be setting the image stride to 0. Unfortunately, some + * software assumes the stride is at least (width * bytes per pixel). We + * therefore require that stride equals (width * bytes per pixel). Since the + * stride is arbitrary here, we pick the simplest convention. + * + * Although containing two sections, compressed image layouts are treated in + * software as a single plane. This is modelled after AFBC, a similar + * scheme. Attempting to separate the sections to be "explicit" in DRM would + * only generate more confusion, as software does not treat the image this way. + * + * For detailed information on the hardware image layouts, see + * https://docs.mesa3d.org/drivers/asahi.html#image-layouts + */ +#define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1) +#define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2) + /* * AMD modifiers * @@ -1571,6 +1739,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) * 64K_D_2D on GFX12 is identical to 64K_D on GFX11. */ #define AMD_FMT_MOD_TILE_GFX9_64K_D 10 +#define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22 #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25 #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26 #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27
Update drm_fourcc.h to Linux kernel version v6.18. As the upstream drm_fourcc.h version doesn't include formats definitions for RAW Bayer formats, we have to re-define some of the symbols we kept downstream as new symbols have been added in mainline with the same values. In particular: -#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 13) +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 18) and -#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0b -#define DRM_FORMAT_MOD_VENDOR_RPI 0x0c +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0e +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0f Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> --- include/linux/drm_fourcc.h | 195 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 182 insertions(+), 13 deletions(-)