linux.git/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c, branch v6.9

drm/amd/display: Add 3x4 CTM support for plane CTM

2023-12-14T20:27:35+00:00

Create drm_color_ctm_3x4 to support 3x4-dimension plane CTM matrix and
convert DRM CTM to DC CSC float matrix.

v3:
- rename ctm2 to ctm_3x4 (Harry)

Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Signed-off-by: Alex Deucher

drm/amd/display: add plane CTM driver-specific property

2023-12-14T20:26:15+00:00

Plane CTM for pre-blending color space conversion. Only enable
driver-specific plane CTM property on drivers that support both pre- and
post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
conflits with DRM CRTC CTM property.

Reviewed-by: Harry Wentland 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: add plane blend LUT and TF driver-specific properties

2023-12-13T21:08:00+00:00

Blend 1D LUT or a pre-defined transfer function (TF) can be set to
linearize content before blending, so that it's positioned just before
blending planes in the AMD color mgmt pipeline, and after 3D LUT
(non-linear space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D
LUT. Drivers should advertize blend properties according to HW caps.

There is no blend ROM for pre-defined TF. When setting blend TF (!=
Identity) and LUT at the same time, the color module will combine the
pre-defined TF and the custom LUT values into the LUT that's actually
programmed.

v3:
- spell out TF+LUT behavior in the commit and comments (Harry)

v5:
- get blend blob correctly

Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: add plane shaper LUT and TF driver-specific properties

2023-12-13T21:08:00+00:00

On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
delinearizing and/or normalizing the color space before applying a 3D
LUT. Add pre-defined transfer function to enable delinearizing content
with or without shaper LUT, where AMD color module calculates the
resulted shaper curve. We apply an inverse EOTF to go from linear
values to encoded values. If we are already in a non-linear space and/or
don't need to normalize values, we can bypass shaper LUT with a linear
transfer function that is also the default TF value.

There is no shaper ROM. When setting shaper TF (!= Identity) and LUT at
the same time, the color module will combine the pre-defined TF and the
custom LUT values into the LUT that's actually programmed.

v2:
- squash commits for shaper LUT and shaper TF
- define inverse EOTF as supported shaper TFs

v3:
- spell out TF+LUT behavior in the commit and comments (Harry)
- replace BT709 EOTF by inv OETF

v5:
- get shaper blob correctly (Joshua)

Reviewed-by: Harry Wentland 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: add plane 3D LUT driver-specific properties

2023-12-13T20:28:38+00:00

Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources.

Since a 3D LUT has a limited number of entries in each dimension we want
to use them in an optimal fashion. This means using the 3D LUT in a
colorspace that is optimized for human vision, such as sRGB, PQ, or
another non-linear space. Therefore, userpace may need one 1D LUT
(shaper) before it to delinearize content and another 1D LUT after 3D
LUT (blend) to linearize content again for blending. The next patches
add these 1D LUTs to the plane color mgmt pipeline.

v3:
- improve commit message about 3D LUT
- describe the 3D LUT entries and size (Harry)

v4:
- advertise 3D LUT max size as the size of a single-dimension

v5:
- get lut3d blob correctly (Joshua)
- fix doc about 3d-lut dimension size (Sebastian)

Signed-off-by: Melissa Wen 
Reviewed-by: Harry Wentland 
Signed-off-by: Alex Deucher

drm/amd/display: add plane HDR multiplier driver-specific property

2023-12-13T20:09:55+00:00

Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
least) When sRGB is decoded, 1.0 -> 1.0.  Therefore, 1.0 multiplier = 80
nits for SDR content. So if you want, 203 nits for SDR content, pass in
(203.0 / 80.0).

v4:
- comment about the PQ TF need for L-to-NL (from Harry's review)

Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Co-developed-by: Melissa Wen 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: add plane degamma TF driver-specific property

2023-12-13T20:09:54+00:00

Allow userspace to tell the kernel driver the input space and,
therefore, uses correct predefined transfer function (TF) to go from
encoded values to linear values.

v2:
- rename TF enum prefix from DRM_ to AMDGPU_ (Harry)
- remove HLG TF

Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Co-developed-by: Melissa Wen 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: add driver-specific property for plane degamma LUT

2023-12-13T20:09:53+00:00

Hook up driver-specific atomic operations for managing AMD color
properties. Create AMD driver-specific color management properties
and attach them according to HW capabilities defined by `struct
dc_color_caps`.

First add plane degamma LUT properties that means user-blob and its
size. We will add more plane color properties in the next patches. In
addition, we define AMD_PRIVATE_COLOR to guard these driver-specific
plane properties.

Plane degamma can be used to linearize input space for arithmetical
operations that are more accurate when applied in linear color.

v2:
- update degamma LUT prop description
- move private color operations from amdgpu_display to amdgpu_dm_color

v5:
- get degamma blob correctly (Joshua)

Reviewed-by: Harry Wentland 
Co-developed-by: Joshua Ashton 
Signed-off-by: Joshua Ashton 
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

drm/amd/display: Add prefix for plane functions

2023-10-26T23:00:09+00:00

This commit adds the amdgpu_dm_plane_ prefix for all functions in the
amdgpu_dm_plane.c. This change enables an easy way to filter code paths
via ftrace.

Reviewed-by: Aurabindo Pillai 
Acked-by: Roman Li 
Signed-off-by: Rodrigo Siqueira 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: switch DC over to the new DRM logging macros

2023-09-26T21:00:21+00:00

For multi-GPU systems it is difficult to tell which GPU a particular
message is being printed for and that is undesirable because it
complicates debugging efforts. Also, the new macros allow us to enable
logging for particular parts of the codebase more selectively (since we
no longer need to throw everything at DRM_DEBUG_KMS()). So, for the
reasons outlined above we should switch to the new macros.

We can accomplish this by using the existing DC_LOGGER code to pass
around the relevant `struct drm_device` which will be fed to the new
macros in logger_types.h. Also, we must get rid of all instances of the
DC_LOG_.*() functions that are currently in amdgpu_dm since we don't use
the DC logger there and we can simply refer to the macros directly
there instead.

Reviewed-by: Rodrigo Siqueira 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher