summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-26drm/colorop: Add 3D LUT support to color pipelineAlex Hung
It is to be used to enable HDR by allowing userpace to create and pass 3D LUTs to kernel and hardware. new drm_colorop_type: DRM_COLOROP_3D_LUT. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-46-alex.hung@amd.com
2025-11-26drm/colorop: allow non-bypass coloropsHarry Wentland
Not all HW will be able to do bypass on all color operations. Introduce an 32 bits 'flags' for all colorop init functions and DRM_COLOROP_FLAG_ALLOW_BYPASS for creating the BYPASS property when it's true. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-45-alex.hung@amd.com
2025-11-26drm/colorop: Define LUT_1D interpolationHarry Wentland
We want to make sure userspace is aware of the 1D LUT interpolation. While linear interpolation is common it might not be supported on all HW. Give driver implementers a way to specify their interpolation. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-44-alex.hung@amd.com
2025-11-26drm/amd/display: Swap matrix and multiplierAlex Hung
Swap the order of matrix and multiplier as designed in hardware. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-43-alex.hung@amd.com
2025-11-26drm/amd/display: add multiplier coloropAlex Hung
This adds support for a multiplier. This multiplier is programmed via the HDR Multiplier in DCN. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-multiply_125 kms_colorop --run plane-XR30-XR30-multiply_inv_125 The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 3x4 CTM 3. Multiplier 4. 1D curve colorop 5. 1D LUT 6. 1D curve colorop 7. 1D LUT Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-42-alex.hung@amd.com
2025-11-26drm/colorop: Add multiplier typeAlex Hung
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER. It's a simple multiplier to all pixel values. The value is specified via a S31.32 fixed point provided via the "MULTIPLIER" property. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-41-alex.hung@amd.com
2025-11-26drm/amd/display: add 3x4 matrix coloropAlex Hung
This adds support for a 3x4 color transformation matrix. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_enc kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 3x4 CTM 3. 1D curve colorop 4. 1D LUT 5. 1D curve colorop 6. 1D LUT Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-40-alex.hung@amd.com
2025-11-26drm/amd/display: add shaper and blend colorops for 1D Curve Custom LUTAlex Hung
This patch adds colorops for custom 1D LUTs in the SHAPER and BLND HW blocks. With this change the following IGT tests pass: kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut The color pipeline now consists of the following colorops: 1. 1D curve colorop 2. 1D curve colorop 3. 1D LUT 4. 1D curve colorop 5. 1D LUT The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-39-alex.hung@amd.com
2025-11-26drm/colorop: Add 1D Curve Custom LUT typeAlex Hung
We've previously introduced DRM_COLOROP_1D_CURVE for pre-defined 1D curves. But we also have HW that supports custom curves and userspace needs the ability to pass custom curves, aka LUTs. This patch introduces a new colorop type, called DRM_COLOROP_1D_LUT that provides a SIZE property which is used by a driver to advertise the supported SIZE of the LUT, as well as a DATA property which userspace uses to set the LUT. DATA and size function in the same way as current drm_crtc GAMMA and DEGAMMA LUTs. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-38-alex.hung@amd.com
2025-11-26drm: Add helper to extract lut from struct drm_color_lut32Chaitanya Kumar Borah
Add helper to extract lut values in 32-bit precision needed by hardware. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-37-alex.hung@amd.com
2025-11-26drm: Add Enhanced LUT precision structureUma Shankar
Existing LUT precision structure drm_color_lut has only 16 bit precision. This is not enough for upcoming enhanced hardwares and advance usecases like HDR processing. Hence added a new structure with 32 bit precision values. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-36-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for BT.709 and BT.2020 TFsHarry Wentland
This adds support for the BT.709/BT.2020 transfer functions on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER, and BLND blocks. With this change the following IGT subtests pass: kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf kms_colorop --run plane-XR30-XR30-bt2020_oetf Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-35-alex.hung@amd.com
2025-11-26drm/colorop: add BT2020/BT709 OETF and Inverse OETFHarry Wentland
The BT.709 and BT.2020 OETFs are the same, the only difference being that the BT.2020 variant is defined with more precision for 10 and 12-bit per color encodings. Both are used as encoding functions for video content, and are therefore defined as OETF (opto-electronic transfer function) instead of as EOTF (electro-optical transfer function). Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-34-alex.hung@amd.com
2025-11-26drm/amd/display: Enable support for PQ 125 EOTF and InverseHarry Wentland
This patchset enables support for the PQ_125 EOTF and its inverse on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER, and BLND blocks. With this patchset the following IGT subtests are passing: kms_colorop --run plane-XR30-XR30-pq_125_eotf kms_colorop --run plane-XR30-XR30-pq_125_inv_eotf kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf-pq_125_eotf Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-33-alex.hung@amd.com
2025-11-26drm/colorop: Add PQ 125 EOTF and its inverseHarry Wentland
The PQ function defines a mapping of code values to nits (cd/m^2). The max code value maps to 10,000 nits. Windows DWM's canonical composition color space (CCCS) defaults to composing SDR contents to 80 nits and uses a float value of 1.0 to represent this. For this reason AMD HW hard-codes a PQ function that is scaled by 125, yielding 80 nit PQ values for 1.0 and 10,000 nits at 125.0. This patch introduces this scaled PQ EOTF and its inverse as 1D curve types. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-32-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB EOTF in BLND blockAlex Hung
Expose a 3rd 1D curve colorop, with support for DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block to perform the sRGB transform when the colorop is not in bypass With this change the following IGT test passes: kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb_eotf The color pipeline now consists of the following colorops: 1. 1D curve colorop w/ sRGB EOTF support 2. 1D curve colorop w/ sRGB Inverse EOTF support 3. 1D curve colorop w/ sRGB EOTF support Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-31-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB Inverse EOTF in SHAPER blockAlex Hung
Expose a 2nd curve colorop with support for DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to perform the sRGB Inverse EOTF on the shaper block when the colorop is not in bypass. With this change the follow IGT tests pass: kms_colorop --run plane-XR30-XR30-srgb_inv_eotf kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf The color pipeline now consists of the following colorops: 1. 1D curve colorop w/ sRGB EOTF support 2. 1D curve colorop w/ sRGB Inverse EOTF support Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-30-alex.hung@amd.com
2025-11-26drm/amd/display: Add support for sRGB EOTF in DEGAM blockAlex Hung
Expose one 1D curve colorop with support for DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform the sRGB transform when the colorop is not in bypass. With this change the following IGT test passes: kms_colorop --run plane-XR30-XR30-srgb_eotf The color pipeline now consists of a single colorop: 1. 1D curve colorop w/ sRGB EOTF Signed-off-by: Alex Hung <alex.hung@amd.com> Co-developed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-29-alex.hung@amd.com
2025-11-26drm/amd/display: Skip color pipeline initialization for cursor planeAlex Hung
cursor plane does not need to have color pipeline. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-28-alex.hung@amd.com
2025-11-26drm/amd/display: Add bypass COLOR PIPELINEHarry Wentland
Add the default Bypass pipeline and ensure it passes the kms_colorop test plane-XR30-XR30-bypass. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-27-alex.hung@amd.com
2025-11-26drm/amd/display: Ignore deprecated props when plane_color_pipeline setHarry Wentland
When the plane_color_pipeline bit is set we should ignore deprecated properties, such as COLOR_RANGE and COLOR_ENCODING. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-26-alex.hung@amd.com
2025-11-26drm/colorop: define a new macro for_each_new_colorop_in_stateAlex Hung
Create a new macro for_each_new_colorop_in_state to access new drm_colorop_state updated from uapi. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-25-alex.hung@amd.com
2025-11-26drm/colorop: pass plane_color_pipeline client cap to atomic checkHarry Wentland
Drivers will need to know whether an atomic check/commit originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE so they can ignore deprecated properties, like COLOR_ENCODING and COLOR_RANGE. Pass the plane_color_pipeline bit to drm_atomic_state. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-24-alex.hung@amd.com
2025-11-26drm/vkms: Add tests for CTM handlingHarry Wentland
A whole slew of tests for CTM handling that greatly helped in debugging the CTM code. The extent of tests might seem a bit silly but they're fast and might someday help save someone else's day when debugging this. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-23-alex.hung@amd.com
2025-11-26drm/tests: Add a few tests around drm_fixed.hHarry Wentland
While working on the CTM implementation of VKMS I had to ascertain myself of a few assumptions. One of those is whether drm_fixed.h treats its numbers using signed-magnitude or twos-complement. It is twos-complement. In order to make someone else's day easier I am adding the drm_test_int2fixp test that validates the above assumption. I am also adding a test for the new sm2fixp function that converts from a signed-magnitude fixed point to the twos-complement fixed point. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-22-alex.hung@amd.com
2025-11-26drm/vkms: add 3x4 matrix in color pipelineHarry Wentland
We add two 3x4 matrices into the VKMS color pipeline. The reason we're adding matrices is so that we can test that application of a matrix and its inverse yields an output equal to the input image. One complication with the matrix implementation has to do with the fact that the matrix entries are in signed-magnitude fixed point, whereas the drm_fixed.h implementation uses 2s-complement. The latter one is the one that we want for easy addition and subtraction, so we convert all entries to 2s-complement. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-21-alex.hung@amd.com
2025-11-26drm/vkms: Use s32 for internal color pipeline precisionHarry Wentland
Certain operations require us to preserve values below 0.0 and above 1.0 (0x0 and 0xffff respectively in 16 bpc unorm). One such operation is a BT709 encoding operation followed by its decoding operation, or the reverse. We'll use s32 values as intermediate in and outputs of our color operations, for the operations where it matters. For now this won't apply to LUT operations. We might want to update those to work on s32 as well, but it's unclear how that should work for unorm LUT definitions. We'll revisit that once we add LUT + CTM tests. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-20-alex.hung@amd.com
2025-11-26drm/colorop: Add 3x4 CTM typeHarry Wentland
This type is used to support a 3x4 matrix in colorops. A 3x4 matrix uses the last column as a "bias" column. Some HW exposes support for 3x4. The calculation looks like: out matrix in |R| |0 1 2 3 | | R | |G| = |4 5 6 7 | x | G | |B| |8 9 10 11| | B | |1.0| This is also the first colorop where we need a blob property to program the property. For that we'll introduce a new DATA property that can be used by all colorop TYPEs requiring a blob. The way a DATA blob is read depends on the TYPE of the colorop. We only create the DATA property for property types that need it. Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-19-alex.hung@amd.com
2025-11-26drm/vkms: Add kunit tests for linear and sRGB LUTsHarry Wentland
Two tests are added to VKMS LUT handling: - linear - inv_srgb Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-18-alex.hung@amd.com
2025-11-26drm/vkms: Add config for default plane pipelineLouis Chauvet
With the introduction of color pipeline in VKMS, the default device may have planes with color pipelines. To avoid breaking existing uAPI, create a kernel argument to disable them by default and a vkms_config field to configure the plane. This field is not definitive and will be replaced once the uAPI will be able to configure color pipelines. For now devices created with ConfigFS will not have any color pipeline so we can decide later how the uAPI will look like. Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-17-alex.hung@amd.com
2025-11-26drm/vkms: Add enumerated 1D curve coloropHarry Wentland
This patch introduces a VKMS color pipeline that includes two drm_colorops for named transfer functions. For now the only ones supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF. We will expand this in the future but I don't want to do so without accompanying IGT tests. We introduce a new vkms_luts.c file that hard-codes sRGB EOTF, sRGB Inverse EOTF, and a linear EOTF LUT. These have been generated with 256 entries each as IGT is currently testing only 8 bpc surfaces. We will likely need higher precision but I'm reluctant to make that change without clear indication that we need it. We'll revisit and, if necessary, regenerate the LUTs when we have IGT tests for higher precision buffers. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-16-alex.hung@amd.com
2025-11-26drm/vkms: Pass plane_cfg to plane initializationLouis Chauvet
As plane can have many parameters, directly pass the plane configuration to the init function. Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-15-alex.hung@amd.com
2025-11-26drm/colorop: Add destroy functions for color pipelineAlex Hung
The functions are to clean up color pipeline when a device driver fails to create its color pipeline. Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-14-alex.hung@amd.com
2025-11-26Documentation/gpu: document drm_coloropHarry Wentland
Add kernel doc for drm_colorop objects. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-13-alex.hung@amd.com
2025-11-26drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINEHarry Wentland
With the introduction of the pre-blending color pipeline we can no longer have color operations that don't have a clear position in the color pipeline. We deprecate all existing plane properties. For upstream drivers those are: - COLOR_ENCODING - COLOR_RANGE Drivers are expected to ignore these properties when programming the HW. DRM clients that register with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE will not be allowed to set the COLOR_ENCODING and COLOR_RANGE properties. Setting of the COLOR_PIPELINE plane property or drm_colorop properties is only allowed for userspace that sets this client cap. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-12-alex.hung@amd.com
2025-11-26drm/plane: Add COLOR PIPELINE propertyHarry Wentland
We're adding a new enum COLOR PIPELINE property. This property will have entries for each COLOR PIPELINE by referencing the DRM object ID of the first drm_colorop of the pipeline. 0 disables the entire COLOR PIPELINE. Userspace can use this to discover the available color pipelines, as well as set the desired one. The color pipelines are programmed via properties on the actual drm_colorop objects. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-11-alex.hung@amd.com
2025-11-26drm/colorop: Add atomic state print for drm_coloropHarry Wentland
Print atomic state for drm_colorop in debugfs Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-10-alex.hung@amd.com
2025-11-26drm/colorop: Add NEXT propertyHarry Wentland
We'll construct color pipelines out of drm_colorop by chaining them via the NEXT pointer. NEXT will point to the next drm_colorop in the pipeline, or by 0 if we're at the end of the pipeline. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-9-alex.hung@amd.com
2025-11-26drm/colorop: Add BYPASS propertyHarry Wentland
We want to be able to bypass each colorop at all times. Introduce a new BYPASS boolean property for this. Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-8-alex.hung@amd.com
2025-11-26drm/colorop: Add 1D Curve subtypeHarry Wentland
Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes: DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF. Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Co-developed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-7-alex.hung@amd.com
2025-11-26drm/colorop: Add TYPE propertyHarry Wentland
Add a read-only TYPE property. The TYPE specifies the colorop type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT, etc. For now we're only introducing an enumerated 1D LUT type to illustrate the concept. Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-6-alex.hung@amd.com
2025-11-26drm/colorop: Introduce new drm_colorop mode objectHarry Wentland
This patches introduces a new drm_colorop mode object. This object represents color transformations and can be used to define color pipelines. We also introduce the drm_colorop_state here, as well as various helpers and state tracking bits. Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-5-alex.hung@amd.com
2025-11-26drm/doc/rfc: Describe why prescriptive color pipeline is neededHarry Wentland
Add documentation for color pipeline API. Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-4-alex.hung@amd.com
2025-11-26drm/vkms: Add kunit tests for VKMS LUT handlingHarry Wentland
Debugging LUT math is much easier when we can unit test it. Add kunit functionality to VKMS and add tests for - get_lut_index - lerp_u16 Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Cc: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-3-alex.hung@amd.com
2025-11-26drm: Add helper for conversion from signed-magnitudeHarry Wentland
CTM values are defined as signed-magnitude values. Add a helper that converts from CTM signed-magnitude fixed point value to the twos-complement value used by drm_fixed. Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-2-alex.hung@amd.com
2025-11-26drm/amdgpu: use ttm_resource_manager_cleanupPierre-Eric Pelloux-Prayer
Rather than open-coding it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251121101315.3585-3-pierre-eric.pelloux-prayer@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2025-11-26drm/ttm: rework pipelined eviction fence handlingPierre-Eric Pelloux-Prayer
Until now ttm stored a single pipelined eviction fence which means drivers had to use a single entity for these evictions. To lift this requirement, this commit allows up to 8 entities to be used. Ideally a dma_resv object would have been used as a container of the eviction fences, but the locking rules makes it complex. dma_resv all have the same ww_class, which means "Attempting to lock more mutexes after ww_acquire_done." is an error. One alternative considered was to introduced a 2nd ww_class for specific resv to hold a single "transient" lock (= the resv lock would only be held for a short period, without taking any other locks). The other option, is to statically reserve a fence array, and extend the existing code to deal with N fences, instead of 1. The driver is still responsible to reserve the correct number of fence slots. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Link: https://lore.kernel.org/r/20251121101315.3585-20-pierre-eric.pelloux-prayer@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-11-26drm/panthor: Reset queue slots if termination failsAshley Smith
Make sure the queue slot is reset even if we failed termination so we don't have garbage in the CS input interface after a reset. In practice that's not a problem because we zero out all RW sections when a hangs occurs, but it's safer to reset things manually, in case we decide to not conditionally reload RW sections based on the type of hang. v4: - Split the changes in two separate patches v5: - No changes v6: - Adjust the explanation in the commit message - Drop the Fixes tag - Put after the timeout changes and make the two patches independent so one can be backported, and the other not v7: - Use the local group variable instead of dereferencing csg_slot->group - Add Steve's R-b v8: - No changes Signed-off-by: Ashley Smith <ashley.smith@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251113105734.1520338-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-11-26drm/panthor: Make the timeout per-queue instead of per-jobAshley Smith
The timeout logic provided by drm_sched leads to races when we try to suspend it while the drm_sched workqueue queues more jobs. Let's overhaul the timeout handling in panthor to have our own delayed work that's resumed/suspended when a group is resumed/suspended. When an actual timeout occurs, we call drm_sched_fault() to report it through drm_sched, still. But otherwise, the drm_sched timeout is disabled (set to MAX_SCHEDULE_TIMEOUT), which leaves us in control of how we protect modifications on the timer. One issue seems to be when we call drm_sched_suspend_timeout() from both queue_run_job() and tick_work() which could lead to races due to drm_sched_suspend_timeout() not having a lock. Another issue seems to be in queue_run_job() if the group is not scheduled, we suspend the timeout again which undoes what drm_sched_job_begin() did when calling drm_sched_start_timeout(). So the timeout does not reset when a job is finished. v2: - Fix syntax error v3: - Split the changes in two commits v4: - No changes v5: - No changes v6: - Fix a NULL deref in group_can_run(), and narrow the group variable scope to avoid such mistakes in the future - Add an queue_timeout_is_suspended() helper to clarify things v7: - No changes v8: - Don't touch drm_gpu_scheduler::timeout in queue_timedout_job() Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Signed-off-by: Ashley Smith <ashley.smith@collabora.com> Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251113105734.1520338-2-boris.brezillon@collabora.com
2025-11-26drm/gem: Correct error condition in drm_gem_objects_lookupSteven Price
When vmemdup_array_user() fails, 'handles' is set to a negative error code and no memory is allocated. So the call to kvfree() should not happen. Instead just return early with the error code. Fixes: cb77b79abf5f ("drm/gem: Use vmemdup_array_user in drm_gem_objects_lookup") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20251124112039.117748-1-steven.price@arm.com
generated by cgit (git 2.34.1) at 2026-01-06 08:48:44 +0000