aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-04-07drm/amd/display: Adjust all dev_*() messages to drm_*()Mario Limonciello1-2/+2
[Why] dev_*() messages don't show that they are from a driver in drm subsystem. [How] Change all dev_*() messages to drm_*() messages. Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-10drm/amd/display: allow 256B DCC max compressed block sizes on gfx12Marek Olšák1-1/+1
The hw supports it. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-03-10Merge tag 'amd-drm-next-6.15-2025-03-07' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie1-2/+5
amdgpu: - Fix spelling typos - RAS updates - VCN 5.0.1 updates - SubVP fixes - DCN 4.0.1 fixes - MSO DPCD fixes - DIO encoder refactor - PCON fixes - Misc cleanups - DMCUB fixes - USB4 DP fixes - DM cleanups - Backlight cleanups and fixes - Support platform backlight curves - Misc code cleanups - SMU 14 fixes - JPEG 4.0.3 reset updates - SR-IOV fixes - SVM fixes - GC 12 DCC fixes - DC DCE 6.x fix - Hiberation fix amdkfd: - Fix possible NULL pointer in queue validation - Remove unnecessary CP domain validation - SDMA queue reset support - Add per process flags radeon: - Fix spelling typos - RS400 hyperZ fix UAPI: - Add KFD per process flags for setting precision Proposed user space: https://github.com/ROCm/ROCR-Runtime/commit/2a64fa5e06e80e0af36df4ce0c76ae52eeec0a9d Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250307211051.1880472-1-alexander.deucher@amd.com
2025-03-07drm/amdgpu/display: Allow DCC for video formats on GFX12David Rosca1-2/+5
We advertise DCC as supported for NV12/P010 formats on GFX12, but it would fail on this check on atomic commit. Signed-off-by: David Rosca <david.rosca@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-02-26Merge tag 'amd-drm-next-6.15-2025-02-21' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie1-1/+1
amd-drm-next-6.15-2025-02-21: amdgpu: - Add OEM i2c support for RGB lights, etc. - Add support for GC 11.5.3 - Add support for GC 11.5.2 - Add support for SDMA 6.1.3 - Add support for NBIO 7.11.2 - Add support for NBIO 7.9.1 - Add support for MMHUB 3.3.2 - Add support for MMHUB 1.8.1 - Add support for SMU 14.0.5 - Add support for SMUIO 13.0.11 - Add support for PSP 14.0.5 - Add support for UMC 12.5.0 - Add support for DCN 3.6.0 - JPEG 4.0.3 updates - Add dynamic workload profile switching for GC 10-12 - support larger vbios sizes - GC 9.5.0 updates - SMU 13.0.12 updates - SMU 13.0.6 updates - IP discovery updates - GC 10 queue reset updates - DCN 4.0.1 updates - UHBR link rate fixes - Aborted suspend fix - Mark gttsize parameter as deprecated - GC 10 cleaner shader updates - PSR-SU fixes - Clean up PM4 headers - Cursor fixes - Enable devcoredump for JPEG - Misc cleanups - Runpm cleanups - MES updates - GC 9 gfxoff fixes - Vbios fetching cleanups - Documentation updates - Update secondary plane handling - DML2 updates - SDMA fixes for MI - Cleaner shader fixes for GC 11/12 - ACA updates - Initial JPEG queue reset support - RAS updates - Initial RAS CPER support - DCN/DCE panic screen handling cleanup - BT2020 fixes - SR-IOV fixes amdkfd: - synchronize pasid values between KGD and KFD - Misc cleanups - Improve GTT/VRAM handling for APUs - Topology updates - Fix user queue validation on GC 7/8 UAPI: - Enable "Broadcast RGB" drm property - Add INFO IOCTL query for virtualization mode Proposed userspace: https://github.com/ROCm/amdsmi/commit/e663bed7d6b3df79f5959e73981749b1f22ec698 From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250221213651.4176031-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-02-19drm/amd/display: Rename panic functionRodrigo Siqueira1-1/+1
Rename dc_plane_force_update_for_panic to dc_plane_force_dcc_and_tiling_disable to describe the function operation in the name. Also, this function might be used in other contexts, and a more generic name can be helpful for this purpose. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-02-14drm/amdgpu: Enable async flip on overlay planesAndré Almeida1-4/+7
amdgpu can handle async flips on overlay planes, so allow it for atomic async checks. Signed-off-by: André Almeida <andrealmeid@igalia.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250127-tonyk-async_flip-v12-2-0f7f8a8610d3@igalia.com [DB: fixed checkpatch warning by adding braces] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-06drm/amd/display: Ensure correct GFX tiling info passed to DMLKarthi Kandasamy1-0/+3
[Why] To ensure DML validation receives the correct tiling information, such as swizzle mode or array mode, based on the active GFX format [How] - For new GFX format passed swizzle_mode to DML. - For legacy GFX format passed array_mode to DML. - Dynamically determined the appropriate tiling info based on the active GFX format. [Description] This commit ensures that the correct GFX tiling information is passed to DML. Depending on the active GFX format, the appropriate tiling info is passed to DML. This change accommodates the different GFX formats supported by latest platforms, ensuring compatibility and proper DML validation. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Karthi Kandasamy <karthi.kandasamy@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-06drm/amd/display: Update dc_tiling_info union to structureKarthi Kandasamy1-7/+7
[WHY] The `dc_tiling_info` union previously did not have a field to specify the active GFX format, assuming only one format would be used per DCN version. from DCN4+, support for switching between different GFX formats is introduced, requiring a way to track which format is currently in use. [HOW] Updated the `dc_tiling_info` union to include a new field that explicitly indicates the currently used GFX format. This allows the system to determine the active GFX format and take the correct programming path accordingly. [Description] The union `dc_tiling_info` has been updated to support multiple GFX formats by adding a new field for identifying the active format. This update ensures that the correct programming path is followed based on the selected format. All references to `dc_tiling_info` in the codebase have been updated to reflect the new structure. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Karthi Kandasamy <karthi.kandasamy@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-12-18Revert "drm/amd/display: Fix green screen issue after suspend"Rodrigo Siqueira1-14/+8
This reverts commit 87b7ebc2e16c14d32a912f18206a4d6cc9abc3e8. A long time ago, we had an issue with the Raven system when it was connected to two displays: one with DP and another with HDMI. After the system woke up from suspension, we saw a solid green screen caused by an underflow generated by bad DCC metadata. To workaround this issue, the 'commit 87b7ebc2e16c ("drm/amd/display: Fix green screen issue after suspend")' was introduced to disable the DCC for a few frames after in the resume phase. However, in hindsight, this solution was probably a workaround at the kernel level for some issues from another part (probably other driver components or user space). After applying this patch and trying to reproduce the green issue in a similar hardware system but using the latest kernel and userspace, we cannot see the issue, which makes this workaround obsolete and creates extra unnecessary complexity to the code; for all of this reason, this commit reverts the original change. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-12-18drm/amd/display: add DC drm_panic supportJocelyn Falempe1-1/+29
Add support for the drm_panic module, which displays a pretty user friendly message on the screen when a Linux kernel panic occurs. It doesn't work yet on laptop panels, maybe due to PSR. Adapted from Jocelyn's original patch to add DC drm_panic support. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Lu Yao <yaolu@kylinos.cn> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com>
2024-09-18drm/amdgpu: explicitely set the AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flagChristian König1-0/+1
Instead of having that in the amdgpu_bo_pin() function applied for all pinned BOs. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-08-27drm/amd/display: do not set traslate_by_source for DCN401 cursorAurabindo Pillai1-1/+4
translate_by_source need not be set for DCN401 onwards since cursor cursor composition comes after scaler in the hardware pipeline. Hence offset calculation has been reworked, and this setting is not necessary to be enabled anymore. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-08-23drm/amd/display: avoid using null object of framebufferMa Ke1-2/+7
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 <make24@iscas.ac.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-08-13drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)Srinivasan Shanmugam1-1/+2
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 <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Co-developed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-10drm/amd/display: Allow display DCC for DCN401Aurabindo Pillai1-6/+25
To enable mesa to use display dcc, DM should expose them in the supported modifiers. Add the best (most efficient) modifiers first. Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-01drm/amdgpu/display: add all gfx12 modifiersMarek Olšák1-5/+6
Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-01drm/amdgpu/display: set plane attributes for gfx12 correctlyMarek Olšák1-1/+49
It used gfx9 flags, which has undefined behavior on gfx12. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-01drm/amdgpu/display: handle gfx12 in amdgpu_dm_plane_format_mod_supportedMarek Olšák1-22/+25
All this code has undefined behavior on GFX12 and shouldn't be executed. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-14drm/amd/display: Move PRIMARY plane zpos higherLeo Li1-5/+13
[Why] Compositors have different ways of assigning surfaces to DRM planes for render offloading. It may decide between various strategies: overlay, underlay, or a mix of both (see here for more info: https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76) One way for compositors to implement the underlay strategy is to assign a higher zpos to the DRM_PRIMARY plane than the DRM_OVERLAY planes, effectively turning the DRM_OVERLAY plane into an underlay plane. Today, amdgpu attaches an immutable zpos of 0 to the DRM_PRIMARY plane. This however, is an arbitrary restriction. DCN pipes are general purpose, and can be arranged in any z-order. To support compositors using this allocation scheme, we can set a non-zero immutable zpos for the PRIMARY, allowing the placement of OVERLAYS (mutable zpos range 0-254) beneath the PRIMARY. [How] Assign a zpos = #no of OVERLAY planes to the PRIMARY plane. Then, clean up any assumptions in the driver of PRIMARY plane having the lowest zpos. v2: Fix typo s/decending/descending/ Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-14drm/amd/display: Introduce overlay cursor modeLeo Li1-1/+12
[Why] DCN is the display hardware for amdgpu. DRM planes are backed by DCN hardware pipes, which carry pixel data from one end (memory), to the other (output encoder). Each DCN pipe has the ability to blend in a cursor early on in the pipeline. In other words, there are no dedicated cursor planes in DCN, which makes cursor behavior somewhat unintuitive for compositors. For example, if the cursor is in RGB format, but the top-most DRM plane is in YUV format, DCN will not be able to blend them. Because of this, amdgpu_dm rejects all configurations where a cursor needs to be enabled on top of a YUV formatted plane. From a compositor's perspective, when computing an allocation for hardware plane offloading, this cursor-on-yuv configuration result in an atomic test failure. Since the failure reason is not obvious at all, compositors will likely fall back to full rendering, which is not ideal. Instead, amdgpu_dm can try to accommodate the cursor-on-yuv configuration by opportunistically reserving a separate DCN pipe just for the cursor. We can refer to this as "overlay cursor mode". It is contrasted with "native cursor mode", where the native DCN per-pipe cursor is used. [How] On each crtc, compute whether the cursor plane should be enabled in overlay mode. If it is, mark the CRTC as requesting overlay cursor mode. Overlay cursor should be enabled whenever there exists a underlying plane that has YUV format, or is scaled differently than the cursor. It should also be enabled if there is no underlying plane, or if underlying planes do not cover the entire CRTC. During DC validation, attempt to enable a separate DCN pipe for the cursor if it's in overlay mode. If that fails, or if no overlay mode is requested, then fallback to native mode. v2: * Update commit message for when overlay cursor should be enabled * Also consider scale and no-underlying-plane case (cursor on crtc bg) * Consider all underlying planes when determinig overlay/native, not just the plane immediately beneath the cursor, as it may not cover the entire CRTC. * Fix typo s/decending/descending/ * Force native cursor on pre-DCN hardware Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-14Revert "drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_update"Ivan Lipski1-12/+4
[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 <srinivasan.shanmugam@amd.com> Tested-by: George Zhang <George.zhang@amd.com> Signed-off-by: Ivan Lipski <ivlipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-14drm/amd/display: Add NULL check for 'afb' before dereferencing in amdgpu_dm_plane_handle_cursor_updateSrinivasan Shanmugam1-4/+12
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 <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Do cursor programming with rest of pipeHarry Wentland1-2/+2
Cursors are always programmed independently of updates on other planes. When atomic commits program cursor and surface updates together the cursor update might be locked out by the surface update and not take effect. To combat this program cursor and surface updates together via dc_update_planes_and_stream to ensure they can be applied atomically. When cursor updates come on their own use the old method to program the cursor as dc_update_planes_and_stream isn't handling this case correctly (yet), leading to a flickering screen. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2186 Reviewed-by: Agustin Gutierrez <agustin.gutierrez@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Separate setting and programming of cursorHarry Wentland1-3/+3
We're seeing issues when user-space tries to do an atomic update of the primary surface, as well as the cursor. These two updates are separate calls into DC and don't currently act as an atomic update. This might lead to cursor updates being locked out and cursors stuttering. In order to solve this problem we want to separate the setting and programming of cursor attributes and position. That's what we're doing in this patch. The subsequent patch will then be able to use the cursor setters in independent cursor updates, as well as in atomic commits. Reviewed-by: Agustin Gutierrez <agustin.gutierrez@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-26drm/amd/display: Add gfx12 modifiersAurabindo Pillai1-0/+15
Expose linear modifier definitions for use with DCN401 Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-14drm/amd/display: Add 3x4 CTM support for plane CTMJoshua Ashton1-1/+1
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 <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-14drm/amd/display: add plane CTM driver-specific propertyMelissa Wen1-0/+21
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 <harry.wentland@amd.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add plane blend LUT and TF driver-specific propertiesJoshua Ashton1-0/+37
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 <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add plane shaper LUT and TF driver-specific propertiesMelissa Wen1-0/+33
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 <harry.wentland@amd.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add plane 3D LUT driver-specific propertiesMelissa Wen1-0/+24
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 <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add plane HDR multiplier driver-specific propertyJoshua Ashton1-0/+13
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 <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Co-developed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add plane degamma TF driver-specific propertyJoshua Ashton1-2/+17
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 <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Co-developed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/amd/display: add driver-specific property for plane degamma LUTMelissa Wen1-0/+85
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 <harry.wentland@amd.com> Co-developed-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-26drm/amd/display: Add prefix for plane functionsRodrigo Siqueira1-269/+273
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 <aurabindo.pillai@amd.com> Acked-by: Roman Li <roman.li@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-09-26drm/amd/display: switch DC over to the new DRM logging macrosHamza Mahfooz1-5/+3
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 <Rodrigo.Siqueira@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-09-20drm/amdgpu: Use function for IP version checkLijo Lazar1-5/+5
Use an inline function for version check. Gives more flexibility to handle any format changes. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-09-06drm/amd/display: enable cursor degamma for DCN3+ DRM legacy gammaMelissa Wen1-0/+7
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 <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-30Revert "Revert "drm/amd/display: Implement zpos property""Hamza Mahfooz1-0/+9
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 <alexander.deucher@amd.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-30drm/amd/display: Add DCN35 DM SupportQingqing Zhuo1-0/+1
[Why & How] Add DM handling for DCN35. Signed-off-by: Qingqing Zhuo <Qingqing.Zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07Revert "drm/amd/display: Implement zpos property"Nicholas Choi1-9/+0
This reverts commit 5b29369b5488d54e466ef7c6a2020a4efc1d854f. This patch causes IGT test case 'kms_atomic@plane-immutable-zpos' to fail on AMDGPU hardware. Cc: Joshua Ashton <joshua@froggi.es> Signed-off-by: Nicholas Choi <Nicholas.Choi@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-07-18drm/amd/display: Implement zpos propertyJoshua Ashton1-0/+9
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 <harry.wentland@amd.com> Cc: Melissa Wen <mwen@igalia.com> Cc: Simon Ser <contact@emersion.fr> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-07-18drm/amd/display: Expose more formats for overlay planes on DCNJoshua Ashton1-16/+25
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 <harry.wentland@amd.com> Cc: Melissa Wen <mwen@igalia.com> Cc: Simon Ser <contact@emersion.fr> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-07-07drm/amd/display: Clean up warnings in amdgpu_dm _mst_types, _plane, _psr.cSrinivasan Shanmugam1-2/+2
Fix the following warnings reported by checkpatch: WARNING: Missing a blank line after declarations WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-08drm/amd/display: add prefix to amdgpu_dm_plane.h functionsDavid Tadokoro1-10/+10
The amdgpu_dm_plane.h functions didn't have names that indicated where they were declared. To better filter results in debug tools like ftrace, prefix these functions with 'amdgpu_dm_plane_'. Note that we may want to make this same change in other files like amdgpu_dm_crtc.h. Signed-off-by: David Tadokoro <davidbtadokoro@usp.br> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-07drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDRHarry Wentland1-129/+0
[Why & How] Remove dead code. Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-14drm/amd/display: Add support for multiple overlay planesBhawanpreet Lakha1-1/+21
[Why] We only allowed 1 overlay plane. But now some ASICS can support multiple overlay planes. [How] Use max_slave_planes as the number of overlays we can support. Also since we cannot draw cursor over a video plane, we need to make sure that we reject commits where the topmost plane is a video plane (overlay only). Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-12-02drm/amd/display: add FB_DAMAGE_CLIPS supportHamza Mahfooz1-0/+4
Currently, userspace doesn't have a way to communicate selective updates to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer than DCN301, convert DRM damage clips to dc dirty rectangles and fill them into dirty_rects in fill_dc_dirty_rects(). Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-10-24drm/amd/display: Revert logic for plane modifiersJoaquín Ignacio Aramendía1-43/+7
This file was split in commit 5d945cbcd4b16a29d6470a80dfb19738f9a4319f ("drm/amd/display: Create a file dedicated to planes") and the logic in dm_plane_format_mod_supported() function got changed by a switch logic. That change broke drm_plane modifiers setting on series 5000 APUs (tested on OXP mini AMD 5800U and HP Dev One 5850U PRO) leading to Gamescope not working as reported on GitHub[1] To reproduce the issue, enter a TTY and run: $ gamescope -- vkcube With said commit applied it will abort. This one restores the old logic, fixing the issue that affects Gamescope. [1](https://github.com/Plagman/gamescope/issues/624) Cc: <stable@vger.kernel.org> # 6.0.x Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-12Merge tag 'amd-drm-next-6.1-2022-09-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie1-2/+3
amd-drm-next-6.1-2022-09-08: amdgpu: - Mode2 reset for RDNA2 - Lots of new DC documentation - Add documentation about different asic families - DSC improvements - Aldebaran fixes - Misc spelling and grammar fixes - GFXOFF stats support for vangogh - DC frame size fixes - NBIO 7.7 updates - DCN 3.2 updates - DCN 3.1.4 Updates - SMU 13.x updates - Misc bug fixes - Rework DC register offset handling - GC 11.x updates - PSP 13.x updates - SDMA 6.x updates - GMC 11.x updates - SR-IOV updates - PSP fixes for TA unloading - DSC passthrough support - Misc code cleanups amdkfd: - ISA fixes for some GC 10.3 IPs - Misc code cleanups radeon: - Delayed work flush fix - Use time_after for some jiffies calculations drm: - DSC passthrough aux support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908155202.57862-1-alexander.deucher@amd.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.