kernel/linux.git/drivers/gpu/drm/drm_fourcc.c, branch v7.2-rc2

drm/fourcc: Add DRM_FORMAT_XVUY2101010

2026-05-05T11:04:29+00:00

Add XVUY2101010, a 10 bits per component YCbCr format in a 32 bit container. Reviewed-by: Laurent Pinchart Reviewed-by: Vishal Sagar Reviewed-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-6-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm/fourcc: Add DRM_FORMAT_T430

2026-05-05T11:04:29+00:00

Add T430, a 3 plane 10 bits per component non-subsampled YCbCr format. A new initial letter was chosen for this one, as the format doesn't match the existing P, Q or S formats. T is the next one in the alphabet. It was definitely not chosen because of the initial letter in the author's name. Reviewed-by: Dmitry Baryshkov Reviewed-by: Vishal Sagar Reviewed-by: Laurent Pinchart Reviewed-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-5-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm/fourcc: Add DRM_FORMAT_XYYY2101010

2026-05-05T11:04:29+00:00

Add XYYY2101010 ("YPA4"), a 10 bit greyscale format, with 3 pixels packed into 32-bit container, and two bits of padding. The fourcc for the format is 'YPA4', which comes from Y - Y only, P - packed, A - 10 (as in 0xA), 4 - 4 bytes. Reviewed-by: Vishal Sagar Reviewed-by: Pekka Paalanen Reviewed-by: Laurent Pinchart Reviewed-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-4-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm/fourcc: Add DRM_FORMAT_Y8

2026-05-05T11:04:29+00:00

Add greyscale Y8 format. The 8-bit greyscale format has been discussed before, and the earlier guidance was to use DRM_FORMAT_R8, as a single-channel 8-bit pixel. However, adding DRM_FORMAT_Y8 makes sense, we can mark it as 'is_yuv' in the drm_format_info, and this can help the drivers handle e.g. full/limited range. This will distinguish two single-channel formats: R8, which is a RGB format with the same value for all components, and Y8, which is a Y-only YCbCr format, with Cb and Cr being neutral. Acked-by: Dmitry Baryshkov Reviewed-by: Pekka Paalanen Reviewed-by: Vishal Sagar Reviewed-by: Laurent Pinchart Acked-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-3-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm/fourcc: Add DRM_FORMAT_P230

2026-05-05T11:04:29+00:00

Add a new pixel format, DRM_FORMAT_P230 ("P230") P230 is 2 plane 10 bit per component YCbCr 2x1 subsampled format. P230 is similar to the already existing P030 format, which is 2x2 subsampled. Reviewed-by: Dmitry Baryshkov Reviewed-by: Vishal Sagar Reviewed-by: Laurent Pinchart Reviewed-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-2-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm/fourcc: Add warning for bad bpp

2026-05-05T11:04:29+00:00

drm_format_info_bpp() cannot be used for formats which do not have an integer bits-per-pixel in a pixel block. E.g. DRM_FORMAT_P030's plane 0 has three 10-bit pixels (Y components), and two padding bits, in a 4 byte block. That is 10.666... bits per pixel when considering the whole 4 byte block, which is what drm_format_info_bpp() does. Thus a driver that supports such formats cannot use drm_format_info_bpp(), It is a driver bug if this happens, but so handle wrong calls by printing a warning and returning 0. Reviewed-by: Laurent Pinchart Reviewed-by: Dmitry Baryshkov Acked-by: Simon Ser Link: https://patch.msgid.link/20260423-xilinx-formats-v10-1-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen

drm: Pass pixel_format+modifier directly to drm_get_format_info()

2025-07-16T17:01:13+00:00

Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just pass the pixel format+modifier combo in by hand. We may want to use drm_get_format_info() outside of the normal addfb paths where we won't have a struct drm_mode_fb_cmd2, and creating a temporary one just for this seems silly. Done with cocci: @@ identifier dev, mode_cmd; @@ struct drm_format_info * drm_get_format_info(struct drm_device *dev, - const struct drm_mode_fb_cmd2 *mode_cmd + u32 pixel_format, u64 modifier ) { <... ( - mode_cmd->pixel_format + pixel_format | - mode_cmd->modifier[0] + modifier ) ...> } @@ identifier dev, mode_cmd; @@ struct drm_format_info * drm_get_format_info(struct drm_device *dev, - const struct drm_mode_fb_cmd2 *mode_cmd + u32 pixel_format, u64 modifier ); @@ expression dev, mode_cmd; @@ - drm_get_format_info(dev, mode_cmd) + drm_get_format_info(dev, mode_cmd->pixel_format, mode_cmd->modifier[0]) v2: Fix kernel docs (Laurent) Drop drm_mode_fb_cmd2 forward declaration (Thomas) Cc: Liviu Dudau Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Patrik Jakobsson Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Cc: Marek Vasut Cc: Stefan Agner Cc: Lyude Paul Cc: Danilo Krummrich Cc: Tomi Valkeinen Cc: Alex Deucher Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Andy Yan Cc: Thierry Reding Cc: Mikko Perttunen Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Reviewed-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Reviewed-by: Liviu Dudau Acked-by: Alex Deucher Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-3-ville.syrjala@linux.intel.com

drm: Pass pixel_format+modifier to .get_format_info()

2025-07-16T16:59:59+00:00

Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just pass the pixel format+modifier combo in by hand. We may want to use .get_format_info() outside of the normal addfb paths where we won't have a struct drm_mode_fb_cmd2, and creating a temporary one just for this seems silly. v2: Fix intel_fb_get_format_info() docs (Laurent) Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Laurent Pinchart Reviewed-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Alex Deucher Acked-by: Rodrigo Vivi Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-2-ville.syrjala@linux.intel.com

drm/fourcc: Add RGB161616 and BGR161616 formats

2025-06-28T07:36:16+00:00

Add FourCC definitions for the 48-bit RGB/BGR formats to the DRM/KMS uapi. The format will be used by the Raspberry Pi PiSP Back End, supported by a V4L2 driver in kernel space and by libcamera in userspace, which uses the DRM FourCC identifiers. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Clark Reviewed-by: Simon Ser Reviewed-by: Naushir Patuck Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas

drm: drm_fourcc: add 10/12/16bit software decoder YCbCr formats

2025-05-29T15:32:58+00:00

This adds FOURCCs for 3-plane 10/12/16bit YCbCr formats used by software decoders like ffmpeg, dav1d and libvpx. The intended use-case is buffer sharing between decoders and GPUs by allocating buffers with e.g. udmabuf or dma-heaps, avoiding unnecessary copies and format conversions in various scenarios. Unlike formats typically used by hardware decoders the 10/12bit formats use a LSB alignment. In order to allow fast implementations in GL and Vulkan the padding must contain only zeros, so the float representation can be calculated by multiplying with 2^6=64 or 2^4=16 respectively. MRs or branches for Mesa, Vulkan, Gstreamer, Weston and Mutter can be found at: - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34303 - https://github.com/rmader/Vulkan-Docs/commits/ycbcr-16bit-lsb-formats/ - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8540 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1753 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4348 The naming scheme follows the 'P' and 'Q' formats. The 'S' stands for 'software' and was selected in order to make remembering easy. The 'Sx16' formats could as well be 'Qx16'. We stick with 'S' as 16bit software decoders are likely much more common than hardware ones for the foreseeable future. Note that these formats already have Vulkan equivalents: - VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM Signed-off-by: Robert Mader Reviewed-by: Daniel Stone Link: https://lore.kernel.org/r/20250509133535.60330-1-robert.mader@collabora.com Signed-off-by: Daniel Stone