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

drm/amd/display: Use same max plane scaling limits for all 64 bpp formats

2026-03-04T12:20:28+00:00

[ Upstream commit f0157ce46cf0e5e2257e19d590c9b16036ce26d4 ]

The plane scaling hw seems to have the same min/max plane scaling limits
for all 16 bpc / 64 bpp interleaved pixel color formats.

Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for
all the 16 bpc fixed-point / unorm formats to use the same .fp16
up/downscaling factor limits as used by the fp16 floating point formats.

So far, 16 bpc unorm formats were not handled, and the default: path
returned max/min factors for 32 bpp argb8888 formats, which were wrong
and bigger than what many DCE / DCN hw generations could handle.

The result sometimes was misscaling of framebuffers with
DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616,
DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested
on Polaris11 / DCE-11.2.

So far this went unnoticed, because only few userspace clients used such
16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they
did not experience this issue.

With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL
and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland
compositor allowing for direct scanout of these formats, the scaling
hw will be used on these formats if possible for HiDPI display scaling,
so it is important to use the correct hw scaling limits to avoid wrong
display.

Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50
on HiDPI displays with scaling enabled. The mutter Wayland compositor now
correctly falls back to scaling via desktop compositing instead of direct
scanout, thereby avoiding wrong image display. For unscaled mode, it
correctly uses direct scanout.

Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.")
Signed-off-by: Mario Kleiner 
Tested-by: Mario Kleiner 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)

2024-10-10T09:57:33+00:00

[ Upstream commit cd9e9e0852d501f169aa3bb34e4b413d2eb48c37 ]

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was
assumed to be null, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.

Changes since v1:
- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Cc: Tom Chung 
Cc: Rodrigo Siqueira 
Cc: Roman Li 
Cc: Alex Hung 
Cc: Aurabindo Pillai 
Cc: Harry Wentland 
Co-developed-by: Alex Hung 
Signed-off-by: Alex Hung 
Signed-off-by: Srinivasan Shanmugam 
Reviewed-by: Tom Chung 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: avoid using null object of framebuffer

2024-09-04T11:28:27+00:00

[ Upstream commit 3b9a33235c773c7a3768060cf1d2cf8a9153bc37 ]

Instead of using state->fb->obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer.

Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Signed-off-by: Ma Ke 
Signed-off-by: Alex Deucher 
(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)
Signed-off-by: Sasha Levin

Revert "drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update"

2024-08-14T11:59:02+00:00

commit 778e3979c5dc9cbdb5d1b92afed427de6bc483b4 upstream.

[WHY]
This patch is a dupplicate implementation of 14bcf29b, which we
are reverting due to a regression with kms_plane_cursor IGT tests.

This reverts commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff.

Reviewed-by: Srinivasan Shanmugam 
Tested-by: George Zhang 
Signed-off-by: Ivan Lipski 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update

2024-08-14T11:58:46+00:00

[ Upstream commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff ]

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was
assumed to be null, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Cc: Tom Chung 
Cc: Rodrigo Siqueira 
Cc: Roman Li 
Cc: Hersen Wu 
Cc: Alex Hung 
Cc: Aurabindo Pillai 
Cc: Harry Wentland 
Signed-off-by: Srinivasan Shanmugam 
Reviewed-by: Harry Wentland 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: enable cursor degamma for DCN3+ DRM legacy gamma

2023-09-07T02:09:33+00:00

For DRM legacy gamma, AMD display manager applies implicit sRGB degamma
using a pre-defined sRGB transfer function. It works fine for DCN2
family where degamma ROM and custom curves go to the same color block.
But, on DCN3+, degamma is split into two blocks: degamma ROM for
pre-defined TFs and `gamma correction` for user/custom curves and
degamma ROM settings doesn't apply to cursor plane. To get DRM legacy
gamma working as expected, enable cursor degamma ROM for implict sRGB
degamma on HW with this configuration.

Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2803
Fixes: 96b020e2163f ("drm/amd/display: check attr flag before set cursor degamma on DCN3+")
Signed-off-by: Melissa Wen 
Signed-off-by: Alex Deucher

Revert "Revert "drm/amd/display: Implement zpos property""

2023-08-31T22:14:49+00:00

This reverts commit e2066eb4efe0e7d2d329d6e6765ed637a523ac45.

The problematic IGT test case (i.e. kms_atomic@plane-immutable-zpos) has
been fixed as of commit cb77add45011 ("tests/kms_atomic: remove zpos <
N-planes assert") to the IGT repo. So, reintroduce the reverted code.

Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/cb77add45011b129e21f3cb2a4089a73dde56179
Acked-by: Alex Deucher 
Reviewed-by: Melissa Wen 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher

Revert "drm/amd/display: Implement zpos property"

2023-08-07T21:13:37+00:00

This reverts commit 5b29369b5488d54e466ef7c6a2020a4efc1d854f.

This patch causes IGT test case 'kms_atomic@plane-immutable-zpos' to
fail on AMDGPU hardware.

Cc: Joshua Ashton 
Signed-off-by: Nicholas Choi 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Implement zpos property

2023-07-18T15:08:53+00:00

Despite certain GPUs supporting multiple overlay planes already in
AMDGPU, the driver did not expose the zpos property which is required
for userspace to take advantage of multiple overlay planes in any
meaningful way.

The driver was already hooked up to normalized_zpos, but was just
missing the exposure of it.

Cc: Harry Wentland 
Cc: Melissa Wen 
Cc: Simon Ser 
Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher

drm/amd/display: Expose more formats for overlay planes on DCN

2023-07-18T15:08:23+00:00

DCN planes are universal and therefore overlay planes can use the same
formats as primary planes, unlike DCE.

Gamescope/Steam Deck would like to take advantage of this functionality
for partial composition which in some cases in our pipeline, can contain
negative values in some instances.

Cc: Harry Wentland 
Cc: Melissa Wen 
Cc: Simon Ser 
Reviewed-by: Harry Wentland 
Signed-off-by: Joshua Ashton 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher