- 09 Apr, 2021 40 commits
-
-
Qu Huang authored
Amdgpu driver uses 4-byte data type as DQM fence memory, and transmits GPU address of fence memory to microcode through query status PM4 message. However, query status PM4 message definition and microcode processing are all processed according to 8 bytes. Fence memory only allocates 4 bytes of memory, but microcode does write 8 bytes of memory, so there is a memory corruption. Changes since v1: * Change dqm->fence_addr as a u64 pointer to fix this issue, also fix up query_status and amdkfd_fence_wait_timeout function uses 64 bit fence value to make them consistent. Signed-off-by:
Qu Huang <jinsdb@126.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Nirmoy Das authored
Offset calculation wasn't correct as start addresses are in pfn not in bytes. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Tom St Denis authored
Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
-
Lijo Lazar authored
Firmware returns zero-based max level, increment by one to get total levels. This fixes the issue of not showing all levels and current frequency when frequency is at max DPM level. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
Evan Quan authored
No need to have special handling for swSMU supported ASICs. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Evan Quan authored
No need to have special handling for swSMU supported ASICs. Signed-off-by:
-
Evan Quan authored
Add "static" declarations for those APIs used internally. Signed-off-by:
-
Evan Quan authored
No need to have special handling for swSMU supported ASICs. Signed-off-by:
-
Evan Quan authored
Correct the check for vblank short. Signed-off-by:
-
Lijo Lazar authored
Fix header guard and make internal functions static. Fixes the below warnings: drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_reset.h:24:9: warning: '__AMDUGPU_RESET_H__' is used as a header guard here, followed by #define of a different macro [-Wheader-guard] drivers/gpu/drm/amd/amdgpu/aldebaran.c:110:6: warning: no previous prototype for function 'aldebaran_async_reset' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/aldebaran_ppt.c:1435:5: warning: no previous prototype for function 'aldebaran_mode2_reset' [-Wmissing-prototypes] Signed-off-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Lijo Lazar authored
Add aldebaran to devices which support recovery Signed-off-by:
-
Lijo Lazar authored
v1: Aldebaran uses reset control to support mode2 reset. The sequences to reset and restore hardware context are specific to a particular configuration. v2: Clear bus mastering before reset. Fix coding style issues, drop unwanted variables and info log. Signed-off-by:
-
Lijo Lazar authored
Expose PG/CG set states functions for other clients Signed-off-by:
-
Lijo Lazar authored
v1: Adds a function to load a list of FWs as passed by the caller. This is needed as only a select need to loaded for some use cases. v2: Omit unrelated change, remove info log, fix return value when count is 0 Signed-off-by:
-
Lijo Lazar authored
This prefers reset control based handling if it's implemented for a particular ASIC. If not, it takes the legacy path. It uses the legacy method of preparing environment (job, scheduler tasks) and restoring environment. v2: remove unused variable (Alex) Signed-off-by:
-
Lijo Lazar authored
v1: Add generic amdgpu_reset_control to handle different types of resets. It may be added at device, hive or ip level. Each reset control has a list of handlers associated with it to handle different types of reset. Reset control is responsible for choosing the right handler given a particular reset context. Handler objects may implement a set of functions on how to handle a particular type of reset. prepare_env = Prepare environment/software context (not used currently). prepare_hwcontext = Prepare hardware context for the reset. perform_reset = Perform the type of reset. restore_hwcontext = Restore the hw context after reset. restore_env = Restore the environment after reset (not used currently). Reset context carries the context of reset, as of now this is based on the parameters used for current set of resets. v2: Fix coding style Signed-off-by:
-
Lijo Lazar authored
v1: On aldebaran, after hardware context restore, another handshake needs to happen with PMFW so that reset recovery is complete from PMFW side. Treat this as RESET_COMPLETE event for aldebaran. v2: Cleanup coding style, info logs Signed-off-by:
-
Lijo Lazar authored
v1: Add function to wait for specific event/states from PMFW v2: Add mutex lock, simplify sequence Signed-off-by:
-
Lijo Lazar authored
v1: During mode2 reset, PCI space is lost after message is sent. Restore PCI space before waiting for response from firmware. v2: Move mode2 sequence to aldebaran and update PMFW version. Handle generic sequence in smu13 without PMFW version check. Signed-off-by:
-
Jack Zhang authored
[Why] Previous tdr design treats the first job in job_timeout as the bad job. But sometimes a later bad compute job can block a good gfx job and cause an unexpected gfx job timeout because gfx and compute ring share internal GC HW mutually. [How] This patch implements an advanced tdr mode.It involves an additinal synchronous pre-resubmit step(Step0 Resubmit) before normal resubmit step in order to find the real bad job. 1. At Step0 Resubmit stage, it synchronously submits and pends for the first job being signaled. If it gets timeout, we identify it as guilty and do hw reset. After that, we would do the normal resubmit step to resubmit left jobs. 2. For whole gpu reset(vram lost), do resubmit as the old way. v2: squash in build fix (Alex) Signed-off-by:
Jack Zhang <Jack.Zhang1@amd.com> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Nirmoy Das authored
BO with ttm_bo_type_sg type can also have tiling_flag and metadata. So so BO type check for only ttm_bo_type_kernel. Reviewed-by:
-
Nirmoy Das authored
Tiling flag and metadata are only needed for BOs created by amdgpu_gem_object_create(), so we can remove those from the base class. v2: * squash tiling_flags and metadata relared patches into one * use BUG_ON for non ttm_bo_type_device type when accessing tiling_flags and metadata._ v3: *include to_amdgpu_bo_user Signed-off-by: -
Nirmoy Das authored
Use amdgpu_bo_create_user() for all the BO allocations for ttm_bo_type_device type. v2: include amdgpu_amdkfd_alloc_gws() as well it calls amdgpu_bo_create() for ttm_bo_type_device Signed-off-by: -
Nirmoy Das authored
Implement a new struct amdgpu_bo_user as subclass of struct amdgpu_bo and a function to created amdgpu_bo_user bo with a flag to identify the owner. v2: amdgpu_bo_to_amdgpu_bo_user -> to_amdgpu_bo_user() Signed-off-by:
-
Nirmoy Das authored
Allow allocating BO structures with different structure size than struct amdgpu_bo. v2: Check bo_ptr_size in all amdgpu_bo_create() caller. Signed-off-by:
-
Christian König authored
Add VCN3 IB parsing to figure out to which instance we can send the stream for decode. v2: remove VCN instance limit as well, fix amdgpu_cs_find_mapping, check supported formats instead of unsupported. v3: fix typo and error handling v4: make sure the message BO is CPU accessible v5: fix addr calculation once more v6: only check message buffers v7: fix constant and use defines v8: fix create msg calculation Signed-off-by:Sonny Jiang <sonny.jiang@amd.com> Signed-off-by:
-
Christian König authored
The VCN3 instances can do both decode as well as encode. Share the scheduler load balancing score and remove fixing encode to only the second instance. Signed-off-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
-
Christian König authored
Allow separate ring to share the same scheduler score. No functional change. Signed-off-by:
-
Sefa Eyeoglu authored
Sometimes the primary plane might not be initialized (yet), which causes dm_check_crtc_cursor to divide by zero. Apparently a weird state before a S3-suspend causes the aforementioned divide-by-zero error when resuming from S3. This was explained in bug 212293 on Bugzilla. To avoid this divide-by-zero error we check if the primary plane's fb isn't NULL. If it's NULL the src_w and src_h attributes will be 0, which would cause a divide-by-zero. This fixes Bugzilla report 212293 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=212293 Fixes: 12f4849a ("drm/amd/display: check cursor scaling") Reviewed-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Sefa Eyeoglu <contact@scrumplex.net> Signed-off-by:
-
Bindu Ramamurthy authored
[Why] idle optimization was being disabled after commit. [How] check vblank count for display off and enable idle optimization based on this count. Also,check added to ensure vblank count does not decrement, when count reaches 0. Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
Bindu Ramamurthy <bindu.r@amd.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/defintion/definition/ .....two different places. Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/acccess/access/ s/inferface/interface/ s/sequnce/sequence/ .....two different places. s/retrive/retrieve/ s/sheduling/scheduling/ s/independant/independent/ s/wether/whether/ ......two different places. s/emmit/emit/ s/synce/sync/ Reviewed-by: Nirmoy Das<nirmoy.das@amd.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/miror/mirror/ s/needind/needing/ s/informations/information/ Acked-by:
-
Arnd Bergmann authored
A previous fix I did left a rather complicated loop in amdgpu_securedisplay_debugfs_write() for what could be expressed in a simple sprintf, as Rasmus pointed out. This drops the leading 0x for each byte, but is otherwise much nicer. Suggested-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Mark Yacoub authored
On initializing the framebuffer, call drm_any_plane_has_format to do a check if the modifier is supported. drm_any_plane_has_format calls dm_plane_format_mod_supported which is extended to validate that the modifier is on the list of the plane's supported modifiers. The bug was caught using igt-gpu-tools test: kms_addfb_basic.addfb25-bad-modifier Tested on ChromeOS Zork by turning on the display, running an overlay test, and running a YT video. === Changes from v1 === Explicitly handle DRM_FORMAT_MOD_INVALID modifier. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by:
Mark Yacoub <markyacoub@chromium.org> Signed-off-by:
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu/drm/amd/pm/amdgpu_pm.c:1940:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:1978:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2022:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:294:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:154:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:512:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:1740:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:1667:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2074:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2047:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2768:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2738:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2442:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3246:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3253:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2458:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3047:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3133:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3209:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3216:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2410:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2470:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2426:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2965:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:2972:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3006:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm/amdgpu_pm.c:3013:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu//drm/amd/amdgpu/amdgpu_ras.c:434:9-17: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:220:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:249:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/df_v3_6.c:208:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_psp.c:2973:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:75:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:112:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:58:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:93:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_vram_mgr.c:125:9-17: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_gtt_mgr.c:52:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_gtt_mgr.c:71:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:140:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:164:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:186:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_device.c:208:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/amd/amdgpu/amdgpu_atombios.c:1916:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu//drm/radeon/radeon_pm.c:521:9-17: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:475:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:418:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:363:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:734:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:688:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:704:8-16: WARNING: use scnprintf or sprintf drivers/gpu//drm/radeon/radeon_pm.c:755:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
-
Alex Deucher authored
The GPU is in the process of being shutdown. Spurious queries during suspend and resume can put the SMU into a bad state. Runtime PM is handled dynamically so we check if we are in non-runtime suspend. Reviewed-by:
-
Alex Deucher authored
They are read only. Noticed-by:
Dave Airlie <airlied@linux.ie> Reviewed-by:
-
