- 03 Oct, 2023 11 commits
-
-
Alex Hung authored
[WHAT] The enable and disable writeback calls need to be included in the coressponding functions in dc_stream. 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
[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:
-
- 28 Sep, 2023 23 commits
-
-
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: Alexander.Deucher@amd.com Reported-by: feifei.xu@amd.com Closes: https://lore.kernel.org/amd-gfx/85b427f6-11ec-4249-bf6f-eadf9c375f88@amd.com/T/#m2887e919d7c01b2a4860d2261b366d22e070f309Signed-off-by:
-
- 26 Sep, 2023 6 commits
-
-
Mario Limonciello authored
The error path for DMUB 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_dmcub.bin failed with error -2 [drm:dm_early_init [amdgpu]] *ERROR* DMUB firmware loading failed: -19 [drm:amdgpu_device_init [amdgpu]] *ERROR* early_init of IP block <dm> failed -19 ``` The error code for the device init is bubbled up already, remove the second one. Signed-off-by:
-
Philip Yang authored
If new range is splited to multiple pranges with max_svm_range_pages alignment and added to update_list, svm validate and map should keep going after error to make sure prange->mapped_to_gpu flag is up to date for the whole range. svm validate and map update set prange->mapped_to_gpu after mapping to GPUs successfully, otherwise clear prange->mapped_to_gpu flag (for update mapping case) instead of setting error flag, we can remove the redundant error flag to simpliy code. Refactor to remove goto and update prange->mapped_to_gpu flag inside svm_range_lock, to guarant we always evict queues or unmap from GPUs if there are invalid ranges. After svm validate and map return error -EAGIN, the caller retry will update the mapping for the whole range again. Fixes: c22b0440 ("drm/amdkfd: flag added to handle errors from svm validate and map") Signed-off-by:
James Zhu <james.zhu@amd.com> Signed-off-by:
-
Le Ma authored
Add xgmi_plpd_policy sysfs node for users to check and select xgmi per-link power down policy: - arg 0: disallow plpd - arg 1: default policy - arg 2: optimized policy v2: split from smu v13.0.6 code and miscellaneous updates v3: add usage comments around set/get functions Signed-off-by:
Asad Kamal <asad.kamal@amd.com> Reviewed-by:
-
Le Ma authored
Add the interface to change xgmi per-link power down policy. v2: split from sysfs interface code and miscellaneous updates v3: check against XGMI_PLPD_DEFAULT/XGMI_PLPD_OPTIMIZED and pass PPSMC param Signed-off-by: -
Le Ma authored
Add enum pp_xgmi_plpd_mode to describe PLPD policies. v2: move the enum from amdgpu_smu.h to kgd_pp_interface.h Signed-off-by:
-
Le Ma authored
To add message to select PLPD mode. Signed-off-by:
-
