- 24 Oct, 2022 22 commits
-
-
David Francis authored
IMU is a new firmware for GFX11. There are four means by which firmware version can be queried from the driver: device attributes, vf2pf, debugfs, and the AMDGPU_INFO_FW_VERSION option in the amdgpu info ioctl. Add IMU as an option for those four methods. V2: Added debugfs Reviewed-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
David Francis <David.Francis@amd.com> Signed-off-by:
-
Deming Wang authored
Using vma_lookup() verifies the start address is contained in the found vma. This results in easier to read the code. Signed-off-by:
Deming Wang <wangdeming@inspur.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
ruanjinjie authored
The symbol is not used outside of the file, so mark it static. Fixes the following warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mpc.c:985:24: warning: symbol 'dcn32_mpc_funcs' was not declared. Should it be static? Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Signed-off-by:
-
ruanjinjie authored
The symbol is not used outside of the file, so mark it static. Fixes the following warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mmhubbub.c:214:28: warning: symbol 'dcn32_mmhubbub_funcs' was not declared. Should it be static? Reviewed-by:
-
ruanjinjie authored
These symbols qp_table_422_10bpc_min, qp_table_444_8bpc_max, qp_table_420_12bpc_max, qp_table_444_10bpc_min, qp_table_420_8bpc_max, qp_table_444_8bpc_min, qp_table_444_12bpc_min, qp_table_420_12bpc_min, qp_table_422_12bpc_min, qp_table_422_12bpc_max, qp_table_444_12bpc_max, qp_table_420_8bpc_min, qp_table_422_8bpc_min, qp_table_422_10bpc_max, qp_table_420_10bpc_max, qp_table_420_10bpc_min, qp_table_444_10bpc_max, qp_table_422_8bpc_max are not used outside of the file, so mark them static. ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:28:18: warning: symbol 'qp_table_422_10bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:61:18: warning: symbol 'qp_table_444_8bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:102:18: warning: symbol 'qp_table_420_12bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:135:18: warning: symbol 'qp_table_444_10bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:188:18: warning: symbol 'qp_table_420_8bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:209:18: warning: symbol 'qp_table_444_8bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:250:18: warning: symbol 'qp_table_444_12bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:315:18: warning: symbol 'qp_table_420_12bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:348:18: warning: symbol 'qp_table_422_12bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:389:18: warning: symbol 'qp_table_422_12bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:430:18: warning: symbol 'qp_table_444_12bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:495:18: warning: symbol 'qp_table_420_8bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:516:18: warning: symbol 'qp_table_422_8bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:541:18: warning: symbol 'qp_table_422_10bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:574:16: warning: symbol 'qp_table_420_10bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:601:18: warning: symbol 'qp_table_420_10bpc_min' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:628:18: warning: symbol 'qp_table_444_10bpc_max' was not declared. Should it be static? ./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:681:18: warning: symbol 'qp_table_422_8bpc_max' was not declared. Should it be static? Signed-off-by:
-
Alex Deucher authored
Commit 8795e182 ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") uncovered a bug in amdgpu that required a reordering of the driver init sequence to avoid accessing a special register on the GPU before it was properly set up leading to an PCI AER error. This reordering uncovered a different hw programming ordering dependency in some APUs where the SDMA doorbells need to be programmed before the GFX doorbells. To fix this, move the SDMA doorbell programming back into the soc15 common code, but use the actual doorbell range values directly rather than the values stored in the ring structure since those will not be initialized at this point. This is a partial revert, but with the doorbell assignment fixed so the proper doorbell index is set before it's used. Fixes: e3163bc8 ("drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega") Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alvin Lee authored
pipe_ctx[i] exists even if the pipe is not in use. If the pipe is not in use it will always have a null stream, so don't return false in this case. Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by:
-
Rodrigo Siqueira authored
When using a device based on DCN32/321, we have an issue where a second 4k@60Hz display does not light up, and the system becomes unresponsive for a few minutes. In the debug process, it was possible to see a hang in the function dcn20_post_unlock_program_front_end in this part: for (j = 0; j < TIMEOUT_FOR_PIPE_ENABLE_MS*1000 && hubp->funcs->hubp_is_flip_pending(hubp); j++) mdelay(1); } The hubp_is_flip_pending always returns positive for waiting pending flips which is a symptom of pipe hang. Additionally, the dmesg log shows this message after a few minutes: BUG: soft lockup - CPU#4 stuck for 26s! ... [ +0.000003] dcn20_post_unlock_program_front_end+0x112/0x340 [amdgpu] [ +0.000171] dc_commit_state_no_check+0x63d/0xbf0 [amdgpu] [ +0.000155] ? dc_validate_global_state+0x358/0x3d0 [amdgpu] [ +0.000154] dc_commit_state+0xe2/0xf0 [amdgpu] This confirmed the hypothesis that we had a pipe hanging somewhere. Next, after checking the ftrace entries, we have the below weird sequence: [..] 2) | dcn10_lock_all_pipes [amdgpu]() { 2) 0.120 us | optc1_is_tg_enabled [amdgpu](); 2) | dcn20_pipe_control_lock [amdgpu]() { 2) | dc_dmub_srv_clear_inbox0_ack [amdgpu]() { 2) 0.121 us | amdgpu_dm_dmub_reg_write [amdgpu](); 2) 0.551 us | } 2) | dc_dmub_srv_send_inbox0_cmd [amdgpu]() { 2) 0.110 us | amdgpu_dm_dmub_reg_write [amdgpu](); 2) 0.511 us | } 2) | dc_dmub_srv_wait_for_inbox0_ack [amdgpu]() { 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); [..] We are not expected to read from dmub register so many times and for so long. From the trace log, it was possible to identify that the function dcn20_pipe_control_lock was triggering the dmub operation when it was unnecessary and causing the hang issue. This commit drops the unnecessary dmub code and, consequently, fixes the second display not lighting up the issue. Tested-by: -
Kenneth Feng authored
allow gfxoff on gc_11_0_3 Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Rodrigo Siqueira authored
Sub-viewport (Subvp) feature is used for changing MCLK without causing any display artifact, requiring special treatment from the plane and stream perspective since DC needs to read data from the cache when using subvp. However, the function dc_commit_updates_for_stream does not provide all the support needed by this feature which will make this function legacy at some point. For this reason, this commit enables dc_update_planes_and_stream for ASICs that support this feature but preserves the old behavior for other ASICs. However, dc_update_planes_and_stream should replace dc_commit_updates_for_stream for all ASICs since it does most of the tasks executed by dc_commit_updates_for_stream with other extra operations, but we need to run tests before making this change. Reviewed-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
-
Rodrigo Siqueira authored
ODM to combine on the eDP panel with ABM causes the color difference to the panel since the ABM module only sets one pipe. Hence, this commit blocks ABM in case of ODM combined on eDP. Reviewed-by:
-
Rodrigo Siqueira authored
OTG instance is not updated in dc_commit_state_no_check for newly committed streams because mode_change is not set. Notice that OTG update is part of the software state, and after hardware programming, it must be updated; for this reason, this commit updates the OTG offset right after hardware programming. Reviewed-by:
-
Rodrigo Siqueira authored
A seamless boot stream has hardware resources assigned to it, and adding a new stream means rebuilding the current assignment. It is desirable to avoid this situation since it may cause light-up issues on the VGA monitor on USB-C. This commit swaps the seamless boot stream to pipe 0 (if necessary) to ensure that the pipe context matches. Reviewed-by:
-
Rodrigo Siqueira authored
DC stream can be seen as a representation of the DCN backend or the data struct that represents the center of the display pipeline. The front end (i.e., planes) is connected to the DC stream, and in its turn, streams are connected to the DC link. Due to this dynamic, DC must handle the following scenarios: 1. A stream is removed; 2. A new stream is created; 3. An unchanged stream had some updates on its planes. These combinations require that the new stream data struct become updated and has a valid global state. For handling multiple corner cases associated with stream operations, this commit introduces a function dedicated to manipulating stream changes and invokes the state validation function after that. Reviewed-by:
-
Rodrigo Siqueira authored
If virtual hardware is detected, there is no reason to run the full dc_commit_streams process, and DC can return true immediately. Reviewed-by:
-
Rodrigo Siqueira authored
The commit stream function does not include surfaces of unaffected streams, which may lead to some blank screens during mode change in some edge cases. This commit adds surfaces of unaffected streams followed by kernel-doc for documenting some of the fields that participate in this change. v2: squash in kerneldoc warning fix (Alex) Reviewed-by:
-
Rodrigo Siqueira authored
DC adds an instance of DML (which contains VBA) to each context, and multiple threads might write back to the global VBA resulting in data overwriting. To keep the consistency with other parts of the DC code, this commit changes dc_commit_streams to copy the current DC state, and as a result, it also changes the function signature to expect streams instead of a context. Reviewed-by:
-
Rodrigo Siqueira authored
Change commit sequence will impact all ASICs. It is prudent to run this update in small steps to keep issues under control and avoid any potential regression. With this idea in mind, this commit is preparation work for the complete transition to the new commit sequence. To maintain this change manageable across multiple ASICs, this commit adds a new function named dc_commit_streams which is a copy of the dc_commit_state with some minor changes. Finally, inside the dc_commit_state, we check if we are using DCN32x or above and enable the new sequence only for those devices. Reviewed-by:
-
Rodrigo Siqueira authored
Context change is all about streams; for this reason, this commit renames context_changed to streams_changed. Additionally, to make this function more flexible, this commit changes the function signature to receive the stream array and the stream count as a parameter. Reviewed-by:
-
Rodrigo Siqueira authored
The link state is set to false if there is no link and local sink. Even though the stream state may not change, it is desirable to commit the new stream when HPD goes low to high. Reviewed-by:
-
Rafael Mendonca authored
If the number of pages from the userptr BO differs from the SG BO then the allocated memory for the SG table doesn't get freed before returning -EINVAL, which may lead to a memory leak in some error paths. Fix this by checking the number of pages before allocating memory for the SG table. Fixes: 264fb4d3 ("drm/amdgpu: Add multi-GPU DMA mapping helpers") Signed-off-by:
Rafael Mendonca <rafaelmendsr@gmail.com> Reviewed-by:
-
Lijo Lazar authored
MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers. Since they are non-existing registers, read access will cause a 'Completer Abort' and gets reported when AER is enabled with the below patch. Tagging with the patch so that this is backported along with it. v2: squash in uninitialized warning fix (Nathan Chancellor) Fixes: 8795e182 ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
- 21 Oct, 2022 3 commits
-
-
Yiqing Yao authored
[why] MES response time in sriov may be longer than default value due to reset or init in other VF. A timeout value specific to sriov is needed. [how] When in sriov, adjust the timeout value to calculated worst case scenario. Signed-off-by:
Yiqing Yao <yiqing.yao@amd.com> Reviewed-by:
-
Kenneth Feng authored
update driver-if header for smu_v13_0_10 and merge with smu_v13_0_0 Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Chengming Gui authored
[WHY] 0, original pstate X 1, ctx_A_create -> ctx_A->stable_pstate = X 2, ctx_A_set_pstate (Y) -> current pstate is Y (PEAK or STANDARD) 3, ctx_B_create -> ctx_B->stable_pstate = Y 4, ctx_A_destroy -> restore pstate to X 5, ctx_B_destroy -> restore pstate to Y Above sequence will cause final pstate is wrong (Y), should be original X. [HOW] When ctx_B create, if ctx_A touched pstate setting (not auto, stable_pstate_ctx != NULL), set ctx_B->stable_pstate the same value as ctx_A saved, if stable_pstate_ctx == NULL, fetch current pstate to fill ctx_B->stable_pstate. Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
-
- 18 Oct, 2022 5 commits
-
-
Rafael Mendonca authored
Commit 902bc65d ("drm/amdgpu/powerplay/psm: return an error in power state init") made the power state init function return early in case of failure to get an entry from the powerplay table, but it missed to clean up the allocated memory for the current power state before returning. Fixes: 902bc65d ("drm/amdgpu/powerplay/psm: return an error in power state init") Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Arunpravin Paneer Selvam authored
A user reported a bug on CAPE VERDE system where uvd_v3_1 IP component failed to initialize as there is an issue with BO move code from one memory to other. In function amdgpu_mem_visible() called by amdgpu_bo_move(), when there are no blocks to compare or if we have a single block then break the loop. Fixes: 312b4dc1 ("drm/amdgpu: Fix VRAM BO swap issue") Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
-
YuBiao Wang authored
[Why] If mes is not dequeued during fini, mes will be in an uncleaned state during reload, then mes couldn't receive some commands which leads to reload failure. [How] Perform MES dequeue via MMIO after all the unmap jobs are done by mes and before kiq fini. v2: Move the dequeue operation inside kiq_hw_fini. Signed-off-by:
YuBiao Wang <YuBiao.Wang@amd.com> Reviewed-by:
Jack Xiao <Jack.Xiao@amd.com> Signed-off-by:
-
Kenneth Feng authored
enable thermal alert on smu_v13_0_10 Signed-off-by:
-
Yifan Zha authored
[Why] L1 blocks most of GC registers accessing by MMIO. [How] Use RLCG interface to program GC registers under SRIOV VF in full access time. Signed-off-by:
Yifan Zha <Yifan.Zha@amd.com> Reviewed-by:
-
- 17 Oct, 2022 10 commits
-
-
Hamza Mahfooz authored
Currently, if we encounter unimplemented functions, it is difficult to tell what caused them just by looking at dmesg and that is compounded by the fact that it is often hard to reproduce said issues, for instance we have had reports of this condition being triggered when removing a secondary display that is setup in mirror mode and is connected using usb-c. So, to have access to more detailed debugging information, add an ASSERT() to dal_irq_service_ack() and dal_irq_service_set() that only triggers when we encounter an unimplemented function. Reviewed-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Nathan Chancellor authored
When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp(): [ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu] (target: hqd_destroy_v10_3+0x0/0x260 [amdgpu]; expected type: 0x8594d794) Clang's kernel Control Flow Integrity (kCFI) makes sure that all indirect call targets have a type that exactly matches the function pointer prototype. In this case, hqd_destroy()'s third parameter, reset_type, should have a type of 'uint32_t' but every implementation of this callback has a third parameter type of 'enum kfd_preempt_type'. Update the function pointer prototype to match reality so that there is no more CFI violation. Link: https://github.com/ClangBuiltLinux/linux/issues/1738Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Fabio M. De Francesco authored
kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and are still valid. Since its use in amdgpu/amdgpu_ttm.c is safe, it should be preferred. Therefore, replace kmap() with kmap_local_page() in amdgpu/amdgpu_ttm.c. Suggested-by:
Ira Weiny <ira.weiny@intel.com> Acked-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Fabio M. De Francesco authored
The use of kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read(). Cc: "Venkataramanan, Anirudh" <anirudh.venkataramanan@intel.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
Guenter Roeck authored
Building 32-bit images may fail with the following error. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c: In function ‘dml32_UseMinimumDCFCLK’: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1: error: the frame size of 1096 bytes is larger than 1024 bytes This is seen when building i386:allmodconfig with any of the following compilers. gcc (Debian 12.2.0-3) 12.2.0 gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 The problem is not seen if the compiler supports GCC_PLUGIN_LATENT_ENTROPY because in that case CONFIG_FRAME_WARN is already set to 2048 even for 32-bit builds. dml32_UseMinimumDCFCLK() was introduced with commit dda4fb85 ("drm/amd/display: DML changes for DCN32/321"). It declares a large number of local variables. Increase the frame size for the affected file to 2048, similar to other files in the same directory, to enable 32-bit build tests with affected compilers. Fixes: dda4fb85 ("drm/amd/display: DML changes for DCN32/321") Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reported-by:
Łukasz Bartosik <ukaszb@google.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Hawking Zhang authored
RAS error address translation algorithm is common across dGPU and A + A platform as along as the SOC integrates the same generation of UMC IP. UMC RAS is managed by x86 MCA on A + A platform, umc_ras in GPU driver is not initialized at all on A + A platform. In such case, any umc_ras callback implemented for dGPU config shouldn't be invoked from A + A specific callback. The change moves convert_error_address out of dGPU umc_ras structure and makes it share between A + A and dGPU config. Signed-off-by:
Stanley Yang <Stanley.Yang@amd.com> Signed-off-by:
-
Tim Huang authored
The pmfw has changed the driver interface version, so keep same with the fw. Signed-off-by:
Tim Huang <tim.huang@amd.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Tim Huang authored
Update the SMU driver interface version to V7. Signed-off-by:
-
ZhenGuo Yin authored
[Why] In SRIOV multi-vf, dpm is always disabled, and pm_attr_list won't be initialized. There will be a NULL pointer call trace after removing the dpm check condition in amdgpu_pm_sysfs_fini. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:amdgpu_device_attr_remove_groups+0x20/0x90 [amdgpu] Call Trace: <TASK> amdgpu_pm_sysfs_fini+0x2f/0x40 [amdgpu] amdgpu_device_fini_hw+0xdf/0x290 [amdgpu] [How] List pm_attr_list should be initialized when dpm is disabled. Fixes: a6ad27ce ("drm/amd/pm: Remove redundant check condition") Signed-off-by:
ZhenGuo Yin <zhenguo.yin@amd.com> Reviewed-by:
-
Evan Quan authored
Suggested by PMFW team and same as what did for gfxoff feature. This can address some Mode1Reset failures observed on SMU13.0.0. Signed-off-by:
-
