- 29 Sep, 2022 3 commits
-
-
YiPeng Chai authored
For the asic using smu v13_0_2, there is the following warning when uninstalling amdgpu: amdgpu: ras disable gfx failed poison:1 ret:-22. [Why]: For the asic using smu v13_0_2, the psp .suspend and mode1reset is called before amdgpu_ras_pre_fini during amdgpu uninstall, it has disabled all ras features and reset the psp. Since the psp is reset, calling amdgpu_ras_disable_all_features in amdgpu_ras_pre_fini to disable ras features will fail. [How]: If all ras features are disabled, amdgpu_ras_disable_all_features will not be called to disable all ras features again. Signed-off-by:
YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Hawking Zhang authored
switch to common helper to initialize rlc firmware for gfx11 Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Hawking Zhang authored
switch to common helper to initialize rlc firmware for gfx10 v2: squash in size validation fix (Alex) Signed-off-by:
-
- 27 Sep, 2022 2 commits
-
-
Hawking Zhang authored
switch to common helper to initialize rlc firmware for gfx9 Signed-off-by:
-
Hawking Zhang authored
To initialzie rlc firmware according to rlc firmware header version v2: squash in backwards compat fix Signed-off-by:
-
- 21 Sep, 2022 12 commits
-
-
Hawking Zhang authored
To initialize rlc firmware in header v2_4 Signed-off-by:
-
Hawking Zhang authored
To initialize rlc firmware in header v2_3 Signed-off-by:
-
Hawking Zhang authored
To initialize rlc firmware in header v2_2 Signed-off-by:
-
Hawking Zhang authored
To initialize rlc firmware in header v2_1 Signed-off-by:
-
Hawking Zhang authored
To initialize rlc firmware in header v2_0 Signed-off-by:
-
Philip Yang authored
Free page table BO from vm resv unlocked context generate below warnings. Add a pt_free_work in vm to free page table BO from vm->pt_freed list. pass vm resv unlock status from page table update caller, and add vm_bo entry to vm->pt_freed list and schedule the pt_free_work if calling with vm resv unlocked. WARNING: CPU: 12 PID: 3238 at drivers/gpu/drm/ttm/ttm_bo.c:106 ttm_bo_set_bulk_move+0xa1/0xc0 Call Trace: amdgpu_vm_pt_free+0x42/0xd0 [amdgpu] amdgpu_vm_pt_free_dfs+0xb3/0xf0 [amdgpu] amdgpu_vm_ptes_update+0x52d/0x850 [amdgpu] amdgpu_vm_update_range+0x2a6/0x640 [amdgpu] svm_range_unmap_from_gpus+0x110/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x535/0x600 [amdgpu] __mmu_notifier_invalidate_range_start+0x1cd/0x230 unmap_vmas+0x9d/0x140 unmap_region+0xa8/0x110 Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Philip Yang authored
Use vm_status_lock to protect all vm_status state transitions to allow them to happen without a reservation lock in unlocked page table updates. Signed-off-by:
-
Philip Yang authored
Use vm_status_lock to protect all vm_status state transitions to allow them to happen without a reservation lock in unlocked page table updates. Signed-off-by:
-
Philip Yang authored
Use vm_status_lock to protect all vm_status state transitions to allow them to happen without a reservation lock in unlocked page table updates. Signed-off-by:
-
Philip Yang authored
Use vm_status_lock to protect all vm_status state transitions to allow them to happen without a reservation lock in unlocked page table updates. Signed-off-by:
-
Philip Yang authored
Use vm_status_lock to protect all vm_status state transitions to allow them to happen without a reservation lock in unlocked page table updates. Signed-off-by:
-
Philip Yang authored
The vm status_lock will be used to protect all vm status lists. Signed-off-by:
-
- 20 Sep, 2022 14 commits
-
-
ye xingchen authored
Return the value atomctrl_initialize_mc_reg_table_v2_2() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
ye xingchen authored
Return the value append_vbios_pptable() directly instead of storing it in another redundant variable. Reported-by:
-
hongao authored
This got lost somewhere along the way, This fixes audio not working until set_property was called. Signed-off-by:
hongao <hongao@uniontech.com> Signed-off-by:
-
Nathan Chancellor authored
Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml314_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with LLVM 16 (1976 -> 1864), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6: error: stack frame size (2216) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1710Reported-by:"kernelci.org bot" <bot@kernelci.org> Tested-by:
Maíra Canal <mairacanal@riseup.net> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
drm/amd/display: Reduce number of arguments of dml314's CalculateWatermarksAndDRAMSpeedChangeSupport() Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with LLVM 16 (2216 -> 1976), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6: error: stack frame size (2216) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1710Reported-by: -
Alex Deucher authored
Some asics still support non-atomic code paths. Fixes: 66f99628 ("drm/amdgpu: use dirty framebuffer helper") Reported-by:
Arthur Marsh <arthur.marsh@internode.on.net> Reviewed-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Christian König authored
Since that has now landed bump the minor to let userspace know about it. Signed-off-by:
-
Christian König authored
The return value is no longer initialized before the loop because of moving code around. Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Evan Quan authored
The pptable in the vbios is fully ready. The related workarounds in driver are not needed any more. Signed-off-by:
Evan Quan <evan.quan@amd.com> Acked-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Evan Quan authored
Enable 3794 pptable support for SMU13.0.0. Signed-off-by:
-
Christian König authored
Allows submitting jobs as gang which needs to run on multiple engines at the same time. All members of the gang get the same implicit, explicit and VM dependencies. So no gang member will start running until everything else is ready. The last job is considered the gang leader (usually a submission to the GFX ring) and used for signaling output dependencies. Each job is remembered individually as user of a buffer object, so there is no joining of work at the end. v2: rebase and fix review comments from Andrey and Yogesh v3: use READ instead of BOOKKEEP for now because of VM unmaps, set gang leader only when necessary v4: fix order of pushing jobs and adding fences found by Trigger. v5: fix job index calculation and adding IBs to jobs v6: fix typo found by Alex Signed-off-by: -
Christian König authored
Allows submitting jobs as gang which needs to run on multiple engines at the same time. Basic idea is that we have a global gang submit fence representing when the gang leader is finally pushed to run on the hardware last. Jobs submitted as gang are never re-submitted in case of a GPU reset since this won't work and will just deadlock the hardware immediately again. v2: fix logic inversion, improve documentation, fix rcu Signed-off-by:
-
Christian König authored
Similar to what we did for VCN3 use the job instead of the parser entity. Cleanup the coding style quite a bit as well. v2: merge improved application check into this patch v3: finally fix the check v4: limit to the correct engine Signed-off-by:
-
Yury Zhuravlev authored
Instead of using RPM speed, we will use a function from vega20 based on PWM registers. Reviewed-by:
Yury Zhuravlev <stalkerg@gmail.com> Signed-off-by:
-
- 19 Sep, 2022 9 commits
-
-
Christian König authored
This reverts commit 250195ff. The job should now be initialized when we reach the parser functions. v2: merge improved application check into this patch v3: back to the original test, but use the right ring Signed-off-by:
-
Christian König authored
Initialize the entity for the CS and scheduler job much earlier. v2: fix job initialisation order and use correct scheduler instance Signed-off-by:
-
Christian König authored
Return early on success and so remove all those "if (r)" in the error path. Signed-off-by:
-
Christian König authored
Cleanup the coding style and function names to represent the data they process for pass2 as well. Go over the chunks only twice now instead of multiple times. v2: fix job initialisation order and use correct scheduler instance v3: try to move all functional changes into a separate patch. v4: separate reordering, pass1 and pass2 change v5: fix va_start calculation v6: fix user fence check Signed-off-by:
-
YiPeng Chai authored
V3: [Why]: Since ASICs using smu v13_0_2 have called smu .suspend before calling amdgpu_pm_sysfs_fini, pm.dpm_enabled was already set to 0 when smu .suspend was called. This makes it impossible to delete all pm sys nodes. [How]: Since all functions in amdgpu_pm_sysfs_fini have their own condition checks, so the first conditional check in amdgpu_pm_sysfs_fini can be removed. Signed-off-by:
-
YiPeng Chai authored
V3: Fixed psp fence and memory issues for the asic using smu v13_0_2 when removing amdgpu device. [Why]: 1. psp_suspend->psp_free_shared_bufs-> psp_ta_free_shared_buf-> amdgpu_bo_free_kernel-> ...->amdgpu_bo_release_notify-> amdgpu_fill_buffer psp will free vram memory used by psp when psp_suspend is called. But for the asic using smu v13_0_2, because psp_suspend is called before adev->shutdown is set to true when removing the first hive device, amdgpu fill_buffer will be called, which will cause fence issues when evicting all vram resources in amdgpu vram mgr_fini. 2. Since psp_hw_fini is not called after calling psp_suspend and psp_suspend only calls psp_ring_stop, the psp ring memory will not be released when amdgpu device is removed. [How]: 1. Set shutdown to true before calling amdgpu_device_gpu_recover, then amdgpu_fill_buffer will not be called when psp_suspend is called. 2. Free psp ring memory in psp_sw_fini. Signed-off-by: -
YiPeng Chai authored
Adjust removal control flow for smu v13_0_2: During amdgpu uninstallation, when removing the first device, the kernel needs to first send a mode1reset message to all gpu devices. Otherwise, smu initialization will fail the next time amdgpu is installed. V2: 1. Update commit comments. 2. Remove the global variable amdgpu_device_remove_cnt and add a variable to the structure amdgpu_hive_info. 3. Use hive to detect the first removed device instead of a global variable. V3: 1. Update commit comments. 2. Split a patch into multiple patches. 3. The current patch does: a. Add a work mode of AMDGPU_RESET_FOR_DEVICE_REMOVE into the existing gpu recover path, which make all devices in hive list only have HW reset but no resume (except the base IP). b. Call AMDGPU_RESET_FOR_DEVICE_REMOVE and AMDGPU_NEED_FULL_RESET mode of amdgpu_device_gpu_recover in amdgpu_pci_remove when removing the first device in hive list. c. When removing the first device, the IP blocks keyword function call sequence is as follows: .suspend->mode1reset->.resume(basic ip)->.hw_fini->.early_fini->.sw_fini. ^ | |-<----------<---------<----| The first three sequences are because of a call to amdgpu_device_gpu_recover. The three sequences will be executed in a loop until all devices in the hive list are iterated. The sequences starting from .hw_fini only apply to the first device. Since .suspend has been called before, except the resumed phase1 basic ip blocks, all other ip blocks .hw_fini of current device will do nothing. d. When removing other devices, the calling sequences is the same as legacy: .hw_fini -> .early_fini -> .sw_fini. Since .suspend has been called when removing the first device, except the resumed phase1 basic ip blocks, all of other ip blocks .hw_fini of current device will do nothing. Signed-off-by: -
Aric Cyr authored
This version brings along following fixes: - Fix urgent latency override for DCN32/DCN321 - Correct hostvm flag in DCN31 - Added new Asic Id for DCN301 - Adjust to 2 phys in DCN301 - Update dummy P-state search to use DCN32 DML - Increase dcn315 pstate change latency - Disable OTG WA for the plane_state NULL case on DCN314 - Update dccg based on HW delta - Correct num_dsc for DCN314 - Fix DP DSC compliance failure with DCN314 - Refactor edp power sequencer codes - update gamut remap if plane has changed - Skip audio setup when audio stream is enabled - Display distortion after hotplug LG Ultrafine 5K tiled display - Fix DP MST timeslot issue when fallback happened - Uncomment SubVP pipe split assignment in driver - Enable committing subvp config - Do second pass through DML for DET calculation - Don't allocate DET for phantom pipes - Modify DML to adjust Vstartup Position - Ignore k1/k2 values for virtual signal to avoid assert - Fix failures of disabling primary planes - Do not compare integers of different widths - Fix empty slot problem of EDID management - Revise Sink device string ID width in dmub psr - Log vertical interrupt 1 for debug Acked-by:
Wayne Lin <wayne.lin@amd.com> Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Charlene Liu authored
[why] num_dsc is 3 for dcn314 based on HW capablity. Reviewed-by:
Martin Leung <Martin.Leung@amd.com> Acked-by:
Charlene Liu <Charlene.Liu@amd.com> Tested-by:
-
