- 04 Nov, 2022 16 commits
-
-
Victor Zhao authored
- clear kiq ring after suspend/resume under sriov to aviod kiq ring test failure - update irq after resume to fix kiq interrput loss Signed-off-by:
Victor Zhao <Victor.Zhao@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Kenneth Feng authored
temporary workaround to skip ras error for gc_v11_0_3 until IFWI release later Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Ma Jun authored
For some GPUs with more CUs, the original sibling_map[32] in struct crat_subtype_cache is not enough to save the cache information when create the VCRAT table, so skip filling the struct crat_subtype_cache info instead fill struct kfd_cache_properties directly to fix this problem. Signed-off-by:
Ma Jun <Jun.Ma2@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Hawking Zhang authored
To allow invoking ip specific callbacks Acked-by:
Le Ma <le.ma@amd.com> Signed-off-by:
-
Nathan Chancellor authored
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:3008:29: error: incompatible function pointer types initializing 'int (*)(void *, uint32_t, long *, uint32_t)' (aka 'int (*)(void *, unsigned int, long *, unsigned int)') with an expression of type 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, uint32_t)' (aka 'int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .odn_edit_dpm_table = smu_od_edit_dpm_table, ^~~~~~~~~~~~~~~~~~~~~ 1 error generated. There are only two implementations of ->odn_edit_dpm_table() in 'struct amd_pm_funcs': smu_od_edit_dpm_table() and pp_odn_edit_dpm_table(). One has a second parameter type of 'enum PP_OD_DPM_TABLE_COMMAND' and the other uses 'u32'. Ultimately, smu_od_edit_dpm_table() calls ->od_edit_dpm_table() from 'struct pptable_funcs' and pp_odn_edit_dpm_table() calls ->odn_edit_dpm_table() from 'struct pp_hwmgr_func', which both have a second parameter type of 'enum PP_OD_DPM_TABLE_COMMAND'. Update the type parameter in both the prototype in 'struct amd_pm_funcs' and pp_odn_edit_dpm_table() to 'enum PP_OD_DPM_TABLE_COMMAND', which cleans up the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/1750Reported-by:Sami Tolvanen <samitolvanen@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:412:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .trans_msg = xgpu_ai_mailbox_trans_msg, ^~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:435:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict] .trans_msg = xgpu_nv_mailbox_trans_msg, ^~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. The type of the second parameter in the prototype should be 'enum idh_request' instead of 'u32'. Update it to clear up the warnings. Link: https://github.com/ClangBuiltLinux/linux/issues/1750Reported-by: -
Paulo Miguel Almeida authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by:
Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Signed-off-by:
-
Paulo Miguel Almeida authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. It's worth mentioning that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/239 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Reviewed-by:
-
Alex Deucher authored
So the callbacks are set early in case we need them. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
So the callbacks are set early in case we need them. Reviewed-by:
-
Alex Deucher authored
So the callbacks are set before we use them. Reviewed-by:
-
Peng Ju Zhou authored
Remove unnecessary register program in SRIOV Signed-off-by:
Peng Ju Zhou <PengJu.Zhou@amd.com> Acked-by:
-
Yiqing Yao authored
[why] Start from soc21, CP does not support MCBP, so disable it. [how] Used amgpu_mcbp flag alone instead of checking if is in SRIOV to enable/disable MCBP. Only set flag to enable on asic_type prior to soc21 in SRIOV. Signed-off-by:
Yiqing Yao <yiqing.yao@amd.com> Reviewed-by:
-
Yiqing Yao authored
Use virt_init_setting instead of per ip version setting. Signed-off-by:
-
Graham Sider authored
Hang on MES timeout if halt_if_hws_hang is set to 1. Signed-off-by:
Graham Sider <Graham.Sider@amd.com> Reviewed-by:
-
Jay Cornwall authored
With corresponding FW change fixes issue where triggering CWSR on a workgroup with waves in s_barrier wouldn't lead to a back-off and therefore cause a hang. Signed-off-by:
Jay Cornwall <jay.cornwall@amd.com> Tested-by:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Acked-by:
-
- 01 Nov, 2022 24 commits
-
-
Jiri Slaby (SUSE) authored
rn_vbios_smu_set_dcn_low_power_state() produces a valid warning with gcc-13: drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c:237:6: error: conflicting types for 'rn_vbios_smu_set_dcn_low_power_state' due to enum/integer mismatch; have 'void(struct clk_mgr_internal *, enum dcn_pwr_state)' drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.h:36:6: note: previous declaration of 'rn_vbios_smu_set_dcn_low_power_state' with type 'void(struct clk_mgr_internal *, int)' I.e. the type of the 2nd parameter of rn_vbios_smu_set_dcn_low_power_state() in the declaration is int, while the definition spells enum dcn_pwr_state. Synchronize them to the latter (and add a forward enum declaration). Cc: Martin Liska <mliska@suse.cz> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by:
-
Aric Cyr authored
DC version 3.2.210 brings along the following: - Investigate tool reported FCLK P-state deviations - Fix null pointer issues found in emulation - Add DSC delay factor workaround - Round up DST_after_scaler to nearest int - Use forced DSC bpp in DML - Fix DCN32 DSC delay calculation - Add a debug option HBR2CP2520 over TPS4 - Stop waiting for vblank during pipe programming - Modify checks to enable TPS3 pattern when required - Remove rate check from pixel rate divider update - Check validation passed after applying pipe split changes - Update DML formula - Don't enable ODM + MPO - Include virtual signal to set k1 and k2 values - Reinit DPG when exiting dynamic ODM Acked-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Tested-by:
Mark Broadworth <mark.broadworth@amd.com> Signed-off-by:
-
Nevenko Stupar authored
[Why] Fix for some of the tool reported modes for FCLK P-state deviations and UCLK P-state deviations that are coming from DSC terms and/or Scaling terms causing MinActiveFCLKChangeLatencySupported and MaxActiveDRAMClockChangeLatencySupported incorrectly calculated in DML for these configurations. Reviewed-by:
Chaitanya Dhere <Chaitanya.Dhere@amd.com> Acked-by:
Jasdeep Dhillon <jdhillon@amd.com> Acked-by:
Nevenko Stupar <Nevenko.Stupar@amd.com> Tested-by:
-
Charlene Liu authored
[why] fix null point issues found in emulation Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
Charlene Liu <Charlene.Liu@amd.com> Tested-by:
-
George Shen authored
[Why] Certain 4K high refresh rate modes requiring DSC are exhibiting top of screen underflow corruption. Increasing the DSC delay by a factor of 6 percent stops the underflow for most use cases. [How] Multiply DSC delay requirement in DML by a factor. Add debug option to make this DSC delay factor configurable. Reviewed-by:
Alvin Lee <Alvin.Lee2@amd.com> Acked-by:
George Shen <george.shen@amd.com> Tested-by:
-
George Shen authored
[Why] The DST_after_scaler value that DML spreadsheet outputs is generally the driver value round up to the nearest int. Reviewed-by:
-
George Shen authored
[Why] DSC config is calculated separately from DML calculations. DML should use these separately calculated DSC params. The issue is that the calculated bpp is not properly propagated into DML. [How] Correctly used forced_bpp value in DML. Reviewed-by:
-
George Shen authored
[Why] DCN32 DSC delay calculation had an unintentional integer division, resulting in a mismatch against the DML spreadsheet. [How] Cast numerator to double before performing the division. Reviewed-by:
-
Anthony Koo authored
- Add flag as a status read back that indicates back to back flips detected during psr. Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Tested-by:
-
Leo Chen authored
[Why & How] There are cases when we may need to override the hardcoded TPS4 test pattern. Added parameters and config option to be able to allow this. Reviewed-by:
Leo Chen <sancchen@amd.com> Tested-by:
-
Martin Leung authored
[why and how] This line was originally removed for a compliance issue, but then reverted as it caused a fringe underflow case. However, the addition of this line caused a underflow regression when subVP is on, and it needs to be removed again. We plan to fix subvp underflow and then re-add in this line. After that, we will investigate what to do next for the compliance issue. Reviewed-by:
Martin Leung <Martin.Leung@amd.com> Tested-by:
-
Iswara Nagulendran authored
[HOW&WHY] Checking if both DSC and FEC supported from sink and source before going with TPS3 pattern during link training. Reviewed-by:
Iswara Nagulendran <iswara.nagulendran@amd.com> Tested-by:
-
Taimur Hassan authored
[Why] This check is not needed, and can cause CRC mismatch. [How] Remove check and early exit from divider update. Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
Taimur Hassan <Syed.Hassan@amd.com> Tested-by:
-
Dillon Varone authored
[WHY?] Validation can fail for configurations that were previously supported, by only changing parameters such as the DET allocations, which is currently unexpected. [HOW?] Add a check that validation passes after applying pipe split related changes. Reviewed-by:
Dillon Varone <Dillon.Varone@amd.com> Tested-by:
-
Charlene Liu authored
[why] This is to update SW DML implementation. Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Ariel Bernstein <Eric.Bernstein@amd.com> Acked-by:
-
Alvin Lee authored
[Description] Driver doesn't support ODM + MPO Reviewed-by:
-
Eric Bernstein authored
Reviewed-by:
-
Dillon Varone authored
[WHY] DPG must be returned to initialized state when pipe is disabled. [HOW] Reinit DPG on unused pipes when exiting dynamic ODM. Reviewed-by:
-
Hamza Mahfooz authored
As of commit 09a5df6c ("drm/amd/display: Fix multi-display support for idle opt workqueue"), vblank_lock is no longer being used. So, don't init it in amdgpu_dm_init() and remove it from struct amdgpu_display_manager. Reviewed-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Ma Jun authored
kfd_topology_device->cache_count is not used by other fucntions, so remove it. Signed-off-by:
-
Yifan Zha authored
[Why] gfxhub_v3_0_3 system aperture registers are removed from RLCG register access range. [How] Skip access gfxhub_v3_0_3 system aperture registers under SRIOV VF. These registers will be programmed on host side. Signed-off-by:
Yifan Zha <Yifan.Zha@amd.com> Acked-by:
-
Yifan Zha authored
[Why] SDMA0_F32_CNTL is a PF_only regitser which will be blocked by L1. RLCG will not program the register as well. [How] Skip to program SDMA0_F32_CNTL under SRIOV VF. Signed-off-by:
-
Yifan Zha authored
[Why] GRBM_CNTL is a PF_only register on gfx_v11. RLCG interface will return "out of range" under SRIOV VF. [How] Skip access GRBM_CNTL under gfx_v11 SRIOV VF. Signed-off-by:
-
Gavin Wan authored
The recent change brought a bug on SRIOV envrionment. It caused unloading amdgpu failed on Guest VM. The reason is that the VF FLR was requested while unloading amdgpu driver, but the VF FLR of SRIOV sequence is wrong while removing PCI device. For SRIOV, the guest driver should not trigger the whole XGMI hive to do the reset. Host driver control how the device been reset. Fixes: f5c7e779 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2") Acked-by:
Shaoyun Liu <Shaoyun.Liu@amd.com> Signed-off-by:
Gavin Wan <Gavin.Wan@amd.com> Signed-off-by:
-
