- 30 Apr, 2020 14 commits
-
-
Zheng Bin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8665:13: warning: variable ‘dc’ set but not used [-Wunused-but-set-variable] It is not used since commit d1ebfdd8 ("drm/amd/display: Unify psr feature flags") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Zheng Bin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1170:39: warning: variable ‘direct_poll’ set but not used [-Wunused-but-set-variable] It is introduced by commit 7daaebfe ("drm/amdgpu: add VCN2.5 sriov start for Arctrus"), but never used, so remove it. Reviewed-by:
Christian König <christian.koenig@amd.com> Reported-by:
-
Zheng Bin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1848:39: warning: variable ‘direct_poll’ set but not used [-Wunused-but-set-variable] It is introduced by commit dd26858a ("drm/amdgpu: implement initialization part on VCN2.0 for SRIOV"), but never used, so remove it. Reviewed-by:
-
Zheng Bin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1211:26: warning: variable ‘priority’ set but not used It is not used since commit 33abcb1f ("drm/amdgpu: set compute queue priority at mqd_init") Reviewed-by:
-
Daniel Kolesa authored
The dcn20_validate_bandwidth function would have code touching the incorrect registers emitted outside of the boundaries of the DC_FP_START/END macros, at least on ppc64le. Work around the problem by wrapping the whole function instead. Signed-off-by:
Daniel Kolesa <daniel@octaforge.org> Signed-off-by:
-
Michel Dänzer authored
Once should generally be enough for diagnosing what lead up to it, repeating it over and over can be pretty annoying. Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
-
Bernard Zhao authored
Maybe no need to check ws before kmalloc, kmalloc will check itself, kmalloc`s logic is if ptr is NULL, kmalloc will just return Reviewed-by:
Bernard Zhao <bernard@vivo.com> Signed-off-by:
-
John Clements authored
RAS TA shall notify driver with flags of error specifics Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
John Clements authored
Update interface to match latest TA Organized input/output structures to better maintain backward compatiblity in the future Reviewed-by:
-
John Clements authored
Parse return status from TA to determine error severity Reviewed-by:
-
Evan Quan authored
At default, the autosuspend delay of audio controller is 3S. If the gpu reset is triggered within 3S(after audio controller idle), the audio controller may be unable into suspended state. Then the sudden gpu reset will cause some audio errors. The change here is targeted to resolve this. However if the audio controller is in use when the gpu reset triggered, this change may be still not enough to put the audio controller into suspend state. Under this case, the gpu reset will still proceed but there will be a warning message printed("failed to suspend display audio"). V2: limit this for BACO and mode1 reset only V3: try 1st to use pm_runtime_autosuspend_expiration() to query how much time is left. Use default setting on failure Signed-off-by:Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Jason Yan authored
The struct member 'asic_setup' was assigned twice, let's remove one: static const struct pp_hwmgr_func smu10_hwmgr_funcs = { ...... .asic_setup = NULL, ...... .asic_setup = smu10_setup_asic_task, ...... }; This fixes the following coccicheck warning: drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1357:52-53: asic_setup: first occurrence line 1360, second occurrence line 1388 Signed-off-by:Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52: exit_optimized_pwr_state: first occurrence line 86, second occurrence line 92 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52: optimize_pwr_state: first occurrence line 85, second occurrence line 91 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52: set_cursor_attribute: first occurrence line 71, second occurrence line 89 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52: set_cursor_position: first occurrence line 70, second occurrence line 88 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52: set_cursor_sdr_white_level: first occurrence line 72, second occurrence line 90 Signed-off-by:
-
Mukul Joshi authored
Track GPU VRAM usage on a per process basis and report it through sysfs. Signed-off-by:
Mukul Joshi <mukul.joshi@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
- 28 Apr, 2020 26 commits
-
-
Joseph Greathouse authored
The current GWS usage model will only allows a single GWS-enabled process to be active on the GPU at once. This ensures that a barrier-using kernel gets a known amount of GPU hardware, to prevent deadlock due to inability to go beyond the GWS barrier. The HWS watches how many GWS entries are assigned to each process, and goes into over-subscription mode when two processes need more than the 64 that are available. The current KFD method for working with this is to allocate all 64 GWS entries to each GWS-capable process. When more than one GWS-enabled process is in the runlist, we must make sure the runlist is in over-subscription mode, so that the HWS gets a chained RUN_LIST packet and continues scheduling kernels. Signed-off-by:
Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by:
-
Joseph Greathouse authored
Rather than only enabling GWS support based on the hws_gws_support modparm, also check whether the GPU's HWS firmware supports GWS. Leave the old modparm in place in case users want to test GWS on GPUs not yet in the support list. v2: fix broken syntax from the first patch. Signed-off-by:
-
Oak Zeng authored
Add a new kfd ioctl to allocate queue GWS. Queue GWS is released on queue destroy. v2: re-introduce this API with the following fixes squashed in: - drm/amdkfd: fix null pointer dereference on dev - drm/amdkfd: Return proper error code for gws alloc API - drm/amdkfd: Remove GPU ID in GWS queue creation Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Alex Sierra authored
Pass unlocked flag value to amdgpu_vm_update_params.unlocked struct member at amdgpu_vm_bo_update_mapping. Reviewed-by:
Alex Sierra <alex.sierra@amd.com> Signed-off-by:
-
Christian König authored
For HMM support we need the ability to invalidate PTEs from a MM callback where we can't lock the root PD. Add a new flag to better support this instead of assuming that all invalidation updates are unlocked. Signed-off-by:
-
Christian König authored
To avoid confusion with direct ring submissions rename bottom of pipe VM table changes to immediate updates. Signed-off-by:
-
Christian König authored
Fix the coding style, move and rename the definitions to better match what they are supposed to be doing. Signed-off-by:
-
Christian König authored
We still need to add the VM update fences to the root PD. So make sure to never sync to those implicitely. Signed-off-by:
-
Alex Deucher authored
We don't support secure operation on compute rings at the moment so reject them. Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
-
Christian König authored
When the node is larger than 4GB we overrun the size calculation. Fix this by correctly limiting the size to the window as well. Signed-off-by:
-
Christian König authored
This should allow us to also support VRAM->GTT moves. v2: fix missing vram_base_adjustment Signed-off-by:
Huang Rui <ray.huang@amd.com> Tested-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by:
-
Christian König authored
Cleanup amdgpu_ttm_copy_mem_to_mem by using fewer variables for the same value. Rename amdgpu_map_buffer to amdgpu_ttm_map_buffer, move it to avoid the forward decleration, cleanup by moving the map decission into the function and add some documentation. No functional change. v2: add some more cleanup suggested by Felix Signed-off-by:
-
Huang Rui authored
Since commit "Move to a per-IB secure flag (TMZ)", we've been seeing hangs in GFX. We need to send FRAME CONTROL stop/start back-to-back, every time we flip the TMZ flag. That is, when we transition from TMZ to non-TMZ we have to send a stop with TMZ followed by a start with non-TMZ, and similarly for transitioning from non-TMZ into TMZ. This patch implements this, thus fixing the GFX hang. v1 -> v2: As suggested by Luben, and accept part of implemetation from this patch: - Put "secure" closed to the loop and use optimization - Change "secure" to bool again, and move "secure == -1" out of loop. v3: Small fixes/optimizations. Reported-and-Tested-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Luben Tuikov authored
Add fine-grained per-ASIC TMZ support. At the moment TMZ support is experimental for all ASICs which support it. Signed-off-by:
-
Christian König authored
Swapping out encrypted BOs doesn't work because they can't change their physical location without going through a bounce copy. As a workaround disable evicting encrypted BOs to the system domain for now. Signed-off-by:
-
Christian König authored
This way we should be at least able to move buffers from VRAM to GTT. Signed-off-by:
-
Christian König authored
This is necessary for TMZ handling during buffer moves and scanout. Signed-off-by:
-
Huang Rui authored
While the current amdgpu doesn't support TMZ, it will return the error if user mode would like to allocate secure buffer. v2: we didn't need this checking anymore. v3: only print message once time. Signed-off-by:
Nirmoy Das <Nirmoy.Das@amd.com> Signed-off-by:
-
Luben Tuikov authored
Move from a per-CS secure flag (TMZ) to a per-IB secure flag. Signed-off-by:
-
Harry Wentland authored
[Why] Hubp needs to know whether a buffer is being scanned out from the trusted memory zone or not. [How] Check for the TMZ flag on the amdgpu_bo and set the tmz_surface flag in dc_plane_address accordingly. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Luben Tuikov authored
Implement an accessor of adev->tmz.enabled. Let not code around access it as "if (adev->tmz.enabled)" as the organization may change. Instead... Recruit "bool amdgpu_is_tmz(adev)" to return exactly this Boolean value. That is, this function is now an accessor of an already initialized and set adev and adev->tmz. Add "void amdgpu_gmc_tmz_set(adev)" to check and set adev->gmc.tmz_enabled at initialization time. After which one uses "bool amdgpu_is_tmz(adev)" to query whether adev supports TMZ. Also, remove circular header file include. v2: Remove amdgpu_tmz.[ch] as requested. v3: Move TMZ into GMC. Signed-off-by:
-
Huang Rui authored
The alignment should match the page size for secure buffer, so we didn't configure it anymore. Signed-off-by:
-
Alex Deucher authored
So it's not mixed up with the CTX stuff. Reviewed-by:
Zhan Liu <zhan.liu@amd.com> Reviewed-by:
-
Aaron Liu authored
This patch enables TMZ bit in FRAME_CONTROL for gfx10. Signed-off-by:
-
Aaron Liu authored
Enable sdma TMZ mode via setting TMZ bit in sdma copy pkt for sdma v5. Signed-off-by:
-
Aaron Liu authored
Enable sdma TMZ mode via setting TMZ bit in sdma copy pkt for sdma v4 Signed-off-by:
-
