- Oct 04, 2023
-
-
Alex Hung authored
[WHAT] Add a function to enable and disable DWB's frame captures. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Hung authored
[WHY] Hardware may require different warmup approaches - big buffer or individual buffers. [HOW] Setup warmup for big buffer when it is required by specific hardware. Reviewed-by:
-
Alex Hung authored
[WHAT] Add a new field to keep track whether a crtc is previously writeback-enabled. Reviewed-by:
-
Alex Hung authored
[WHY] Counter j was not updated to present the num of writeback_info when writeback pipes are removed. [HOW] update j (num of writeback info) under the correct condition. Reviewed-by:
-
Alex Hung authored
[WHAT] hw_points_num is 0 before ogam LUT is programmed; however, function "dwb3_program_ogam_pwl" assumes hw_points_num is always greater than 0, i.e. substracting it by 1 as an array index. [HOW] Check hw_points_num is not equal to 0 before using it. Reviewed-by:
-
Alex Hung authored
[WHY] wb_enabled field is set to false before it is used, and the following code will never be executed. [HOW] Setting wb_enable to false after all removal work is completed. Reviewed-by:
-
Alex Hung authored
[WHAT] The enable and disable writeback calls need to be included in the coressponding functions in dc_stream. Reviewed-by:
-
Alex Hung authored
[WHAT] Handle writeback requests and fill in the required information for DWB programming and setup. Reviewed-by:
-
Harry Wentland authored
[WHAT] Writeback connectors don't have a physical sink but DC still needs a sink to function. Create a fake sink and stream for writeback connectors Reviewed-by:
-
Harry Wentland authored
[WHY] We need to track the dc_link and it would get confusing if re-using the amdgpu_dm_connector. [HOW] Creating new amdgpu_dm_wb_connector. Reviewed-by:
-
Harry Wentland authored
[WHAT] Again, we need to use this function for writeback connectors, which are not of type amdgpu_dm_connector. Use the common base drm_connector instead. Reviewed-by:
-
Srinivasan Shanmugam authored
Fixes the following: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3928: warning: Function parameter or member 'srf_updates' not described in 'could_mpcc_tree_change_for_active_pipes' Cc: Harry Wentland <harry.wentland@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Acked-by:
-
Dan Carpenter authored
"ret" was checked earlier inside the loop, so we know it is zero here. No need to check a second time. Reviewed-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Harry Wentland authored
[WHAT] We need to use this function for both amdgpu_dm_connectors and drm_writeback_connectors. Modify it to operate on a drm_connector as a common base. Reviewed-by:
-
Alex Deucher authored
I think this was an abstraction back from when kfd supported both radeon and amdgpu. Since we just support amdgpu now, there is no more need for this and we can use the amdgpu structures directly. This also avoids having the kfd_cu_info structures on the stack when inlining which can blow up the stack. Cc: Arnd Bergmann <arnd@kernel.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Harry Wentland authored
[WHY] We will be dealing with two types of connector: amdgpu_dm_connector and drm_writeback_connector. [HOW] We want to find both and then cast to the appriopriate type afterwards. Reviewed-by:
-
Alex Deucher authored
kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger than 1024 bytes Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866 Cc: Arnd Bergmann <arnd@kernel.org> Acked-by:
-
- Sep 29, 2023
-
-
Tao Zhou authored
Increase the retry loops and replace the constant number with macro. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Harry Wentland authored
[WHY] Writeback connectors are based on a different object: drm_writeback_connector, and are therefore different from amdgpu_dm_connector. We need to be careful to ensure code designed for amdgpu_dm_connector doesn't inadvertently try to operate on a drm_writeback_connector. [HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK. Reviewed-by:
-
Tao Zhou authored
No need to perform the full reset operation in case of gpu reset failure. Signed-off-by:
-
Victor Zhao authored
disable pp_power_profile_mode for sriov on gc11.0.3 as not supported by smu Signed-off-by:
Victor Zhao <Victor.Zhao@amd.com> Acked-by:
-
Xiaogang Chen authored
prange->svm_bo unref can happen in both mmu callback and a callback after migrate to system ram. Both are async call in different tasks. Sync svm_bo unref operation to avoid random "use-after-free". Signed-off-by:
Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
Jesse Zhang <Jesse.Zhang@amd.com> Tested-by:
-
Michel Dänzer authored
It was only checking planes which had any state changes in the same commit. However, it also needs to check other enabled planes. Not doing this meant that a commit might spuriously "succeed", resulting in the cursor plane displaying with incorrect scaling. See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1824263 for an example. Fixes: d1bfbe8a ("amd/display: check cursor plane matches underlying plane") Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Alex Hung authored
[WHAT] Create a drm_writeback_connector when connector signal equals SIGNAL_TYPE_VIRTUAL. Reviewed-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
-
Mario Limonciello authored
As part of IP discovery early_init is run for all HW IP blocks. During this phase all firmware is supposed to be identified that may be missing so that the driver can avoid releasing resources used by the EFI framebuffer or simpledrm until the last possible moment. Move microcode loading from sw_init to early_init. Signed-off-by:
-
Cong Liu authored
This patch fixes a null pointer dereference in the error message that is printed when the Display Core (DC) fails to initialize. The original message includes the DC version number, which is undefined if the DC is not initialized. Fixes: 9788d087 ("drm/amd/display: improve the message printed when loading DC") Signed-off-by:
Cong Liu <liucong2@kylinos.cn> Reviewed-by:
-
Harry Wentland authored
[WHAT] Prepare a virtual connector for writeback. Reviewed-by:
-
Mario Limonciello authored
The error path for SDMA firmware loading is unnecessarily noisy. When a firmware is missing 3 errors show up: ``` amdgpu 0000:07:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin failed with error -2 [drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware! [drm:amdgpu_device_init [amdgpu]] *ERROR* early_init of IP block <sdma_v4_0> failed -19 ``` The error code for the device init is bubbled up already, remove the second one. Signed-off-by:
-
Le Ma authored
Pass the correct size to smu_v13_0_6_print_clks, otherwise the same place in buf will be re-written. Signed-off-by:
Le Ma <le.ma@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Le Ma authored
Replace with set_plpd_mode uniformly for places to use. Signed-off-by:
-
Le Ma authored
The allow_xgmi_power_down(true/false) will be generally replaced by: - allow: select_xgmi_plpd_policy(XGMI_PLPD_DEFAULT) - disallow: select_xgmi_plpd_policy(XGMI_PLPD_DISALLOW) Signed-off-by:
-
Le Ma authored
Assign DEFAULT mode if it supports plpd, otherwise keeps NONE v2: reduce ip version checks Signed-off-by:
-
Stylon Wang authored
[Why & How] These DPCD addresses are either declared in other header files where it makes more sense or simply not used by any DC code. Remove them to reduce redundancies and potential confusion. Reviewed-by:
Stylon Wang <stylon.wang@amd.com> Signed-off-by:
-
Harry Wentland authored
[WHY] Previously this only excluded build for a few amdgpu_dm binaries which makes no sense. [HOW] Wrap the entire Makefile in "ifneq ($(CONFIG_DRM_AMD_DC),)" Reviewed-by:
-
Mario Limonciello authored
A hang is reported on DCN 3.2 with seamless boot enabled. As the benefits come from an eDP setup, limit it to only enabled by default with APUs. Suggested-by:
<feifei.xu@amd.com> Closes: https://lore.kernel.org/amd-gfx/85b427f6-11ec-4249-bf6f-eadf9c375f88@amd.com/T/#m2887e919d7c01b2a4860d2261b366d22e070f309 Signed-off-by:
-
