- 22 Feb, 2021 5 commits
-
-
Rodrigo Siqueira authored
When run igt@kms_vrr in a device that uses DCN2.1 architecture, we noticed multiple failures. Furthermore, when we tested a VRR demo, we noticed a system hang where the mouse pointer still works, but the entire system freezes; in this case, we don't see any dmesg warning or failure messages kernel. This happens due to a lack of vupdate_no_lock interrupt, making the userspace wait eternally to get the event back. For fixing this issue, we need to add the vupdate_no_lock interrupt in the interrupt list. Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
Bindu Ramamurthy <bindu.r@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Nirmoy Das authored
Fixes: 62914a99 ("drm/amdgpu: Use mmu_interval_insert instead of hmm_mirror") Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Felix Kuehling authored
If init_cwsr_apu fails, we currently leave the kfd_process structure in place anyway. The next kfd_open will then succeed, using the existing kfd_process structure. Fix that by cleaning up the kfd_process after a failure in init_cwsr_apu. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Philip Yang <philip.yang@amd.com> Signed-off-by:
-
Felix Kuehling authored
We use mmu_notifier_put to free the MMU notifier. That needs to be paired with mmu_notifier_get to work correctly. Othewrise the next patch would cause a kernel oops. Signed-off-by:
-
Anson Jacob authored
This reverts commit 8866a67a. Reason for revert: This breaks hotplug of HDMI on some systems, resulting in a blank screen. Caused general hangs on boot/hotplugs. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1487 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1492 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211649Signed-off-by:
Anson Jacob <Anson.Jacob@amd.com> Reviewed-by:
Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Acked-by:
-
- 18 Feb, 2021 35 commits
-
-
Yang Li authored
Fix the following coccicheck warning: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8142:16-21: WARNING: conversion to bool not needed here Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Huang Rui authored
We should commit the value after restore them back to default as well. $ echo "r" > pp_od_clk_voltage $ echo "c" > pp_od_clk_voltage Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Aurabindo Pillai authored
New proposed sequence for HUBP blanking causes regressions where the hardware would fail to enter blank which triggers an assert in the new sequence. This change brings back the old sequence. Fixes: 985faf2c ("drm/amd/display: New sequence for HUBP blank") Signed-off-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
-
Nirmoy Das authored
Mark amdgpu_ras_debugfs_create_ctrl_node() as static. Fixes: eb14235668777b ("drm/amdgpu: do not keep debugfs dentry") Reported-by:kernel test robot <lkp@intel.com> Reviewed-by:
-
Aric Cyr authored
DC version 3.2.123 brings improvements in multiple areas. In summary, we highlight: - Firmware release 0.0.52 - Bug fixes on MPC OGAM sequence, display experience, etc. - Improvements on timing, transmitter control, etc. Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Qingqing Zhuo <Qingqing.Zhuo@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Anthony Koo authored
[How] Add new aux cmd fields for acquire and release Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Eric Bernstein authored
[Why] Moving definition of transmitter control from atomfirmware to internal header. [How] Update the command table code to call 1.7 and make it the default fallback path. Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
-
Chris Park authored
[Why] Simplify AVMUTE logic in coding [How] Avoid multiple calls on TMDS AVMUTE as updated logic now demands it. Signed-off-by:
Chris Park <Chris.Park@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Sung Lee authored
[Why] With certain fclock overclocks, state 1 may be chosen as the closest clock level. This may result in this state being empty if not populated beforehand, resulting in black screens and screen corruption. [How] Copy over all soc states to clock_limits before bounding box creation to avoid any cases with empty states. Signed-off-by:
Sung Lee <sung.lee@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Reviewed-by:
Yongqiang Sun <yongqiang.sun@amd.com> Acked-by:
-
Stylon Wang authored
[Why] Add necessary support for Freesync HDMI in Linux DM [How] - Support Freesync HDMI by calling DC interace - Report Freesync capability to vrr_range debugfs from DRM - Depends on coming DMCU/DMUB firmware to enable feature Signed-off-by:
Stylon Wang <stylon.wang@amd.com> Reviewed-by:
-
Sung Lee authored
[Why] If system is overclocked, only 1 bounding box state will be sent by SMU. This results in an empty state being copied for DML calculations causing black screens and corruption. [How] Fully populate bounding box before duplicating last state. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Color corruption can occur on bootup into a login manager that applies a non-linear gamma LUT because the LUT may not actually be powered on before writing. It's cleared on the next full pipe reprogramming as we switch to LUTB from LUTA and the pipe accessing the LUT has taken it out of light sleep mode. [How] The MPCC_OGAM_MEM_PWR_FORCE register does not force the current power mode when set to 0. It only forces when set light sleep, deep sleep or shutdown. The register to actually force power on and ignore sleep modes is MPCC_OGAM_MEM_PWR_DIS - a value of 0 will enable power requests and a value of 1 will disable them. When PWR_FORCE!=0 is combined with PWR_DIS=0 then MPCC OGAM memory is forced into the state specified by the force bits. If PWR_FORCE is 0 then it respects the mode specified by MPCC_OGAM_MEM_LOW_PWR_MODE if the RAM LUT is not in use. We set that bit to shutdown on low power, but otherwise it inherits from bootup defaults. So for the fix: 1. Update the sequence to "force" power on when needed We can use MPCC_OGAM_MEM_PWR_DIS for this to turn on the memory even when the block is in bypass and pending to be enabled for the next frame. We need this for both low power enabled or disabled. If we don't set this then we can run into issues when we first program the LUT from bootup. 2. Don't apply FORCE_SEL Once we enable power requests with DIS=0 we run into the issue of the RAM being forced into light sleep and being unusable for display output. Leave this 0 like we used to for DCN20. 3. Rely on MPCC OGAM init to determine light sleep/deep sleep MPC low power debug mode isn't enabled on any ASIC currently but we'll respect the setting determined during init if it is. Lightly tested as working with IGT tests and desktop color adjustment. 4. Change the MPC resource default for DCN30 It was interleaving the dcn20 and dcn30 versions before depending on the sequence. 5. REG_WAIT for it to be on whenever we're powering up the memory Otherwise we can write register values too early and we'll get corruption. Signed-off-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] We added these in DMCUB for runtime feature detection but we didn't have helpers to call these with DC error handling/logging. [How] Add helpers. Signed-off-by:
-
Martin Leung authored
[Why] Hardware team remeasured, need to update timings to increase latency slightly and avoid intermittent underflows. [How] sr exit latency update. Signed-off-by:
Martin Leung <martin.leung@amd.com> Reviewed-by:
Alvin Lee <Alvin.Lee2@amd.com> Acked-by:
-
Wesley Chalmers authored
This reverts commit fd1c85d3 [Why] We are not implementing the planned new HW sequence to disable HUBP. [How] Revert most related changes to minimize possibility of regression. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by:
-
Wesley Chalmers authored
This reverts commit f8e792dc [Why] We are not implementing the planned new HW sequence for HUBP disable. [How] Revert most related changes to minimize regressions. Signed-off-by:
-
Lewis Huang authored
[Why] In following sequence driver will add counter twice on same edp stream. 1. Boot into OS. 2. Set timing with edp only. 3. Set timing with edp and external monitor. 4. Set visibility on for edp. Step 2 and 3 will add seamless boot counter twice and subtract it once in step 4. [How] Remove global counter and calculate it is used. Signed-off-by:
Lewis Huang <Lewis.Huang@amd.com> Reviewed-by:
-
Po-Ting Chen authored
[Why] To get the pixel statistics on every frame, change ABM sample rate from 2 to 1. [How] Change LS, HS and BL sample rate to 1. Signed-off-by:
Po-Ting Chen <robin.chen@amd.com> Reviewed-by:
-
Nirmoy Das authored
Use debugfs API directly instead of drm middle layer. v2: squash in build fix (Alex) Signed-off-by:
-
Nirmoy Das authored
Retrieving radeon device struct from ring struct will be used in next patch where debugfs's show function can only pass one private data pointer. Signed-off-by:
-
Chen Lin authored
Remove the 'radeon_packet3_check_t' typedef as it is not used. Reviewed-by:
Chen Lin <chen.lin5@zte.com.cn> Signed-off-by:
-
Gustavo A. R. Silva authored
drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct NISLANDS_SMC_SWSTATE, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/gpu/drm/radeon/ni_dpm.c: In function ‘ni_convert_power_state_to_smc’: drivers/gpu/drm/radeon/ni_dpm.c:2521:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2521 | smc_state->levels[i].dpm2.MaxPS = | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2523:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2523 | smc_state->levels[i].dpm2.NearTDPDec = NISLANDS_DPM2_NEAR_TDP_DEC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2524:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2524 | smc_state->levels[i].dpm2.AboveSafeInc = NISLANDS_DPM2_ABOVE_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2525:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2525 | smc_state->levels[i].dpm2.BelowSafeInc = NISLANDS_DPM2_BELOW_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ^~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ 2527 | ((i != (state->performance_level_count - 1)) && power_boost_limit) ? | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2528 | PPSMC_STATEFLAG_POWERBOOST : 0; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ni_dpm.c:2442:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2442 | smc_state->levels[i + 1].aT = cpu_to_be32(a_t); [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109Build-tested-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
drm/amd/pm: Replace one-element array with flexible-array in struct _ATOM_Vega10_GFXCLK_Dependency_Table There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct _ATOM_Vega10_GFXCLK_Dependency_Table, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warning: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function ‘vega10_get_pp_table_entry_callback_func’: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3113:30: warning: array subscript 4 is above array bounds of ‘ATOM_Vega10_GFXCLK_Dependency_Record[1]’ {aka ‘struct _ATOM_Vega10_GFXCLK_Dependency_Record[1]’} [-Warray-bounds] 3113 | gfxclk_dep_table->entries[4].ulClk; | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109Build-tested-by: -
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2448:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2449:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2450:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2451:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2452:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:5570:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109Build-tested-by: -
Colin Ian King authored
There are spelling mistakes in error and warning messages, the text power_dpm_force_perfomance_level is missing a letter r and should be power_dpm_force_performance_level. Fix them. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Nirmoy Das authored
Use debugfs API directly instead of drm middle layer. This also includes following debugfs file output changes: 1 amdgpu_evict_vram/amdgpu_evict_gtt output will not contain any braces. e.g. (0) --> 0 2 amdgpu_gpu_recover output will print return value of amdgpu_device_gpu_recover() instead of not so important "gpu recover" message. v2: * checkpatch.pl: use '0444' instead of S_IRUGO. * remove S_IFREG from mode. * remove mode variable. Signed-off-by: -
Nirmoy Das authored
Use debugfs API directly instead of drm middle layer. v2: * checkpatch.pl: use '0444' instead of S_IRUGO. * remove S_IFREG from mode. * remove mode variable. Signed-off-by: -
Nirmoy Das authored
Use debugfs API directly instead of drm middle layer. v2: * checkpatch.pl: use '0444' instead of S_IRUGO. * remove S_IFREG from mode. * remove mode variable. Signed-off-by: -
Nirmoy Das authored
Removed unused CONFIG_DRM_AMDGPU_GART_DEBUGFS code. We can use umr instead of this gart debugfs. Signed-off-by:
-
Nirmoy Das authored
Remove unnecessary debugfs dentries and also radeon_ttm_debugfs_fini() as drm_debugfs_cleanup() will recursively remove debugfs files. Signed-off-by:
-
Nirmoy Das authored
Cleanup unnecessary debugfs dentries and surrounding functions. v3: remove return value check for debugfs_create_file() v2: remove ttm_debugfs_entries array. do not init variables. Signed-off-by: -
Alex Deucher authored
Fixes the rlc reference clock used for GPU timestamps. Value is 100Mhz. Confirmed with hardware team. v2: reword commit message. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480Acked-by:
-
Alex Deucher authored
Disable it on those boards. No functional change, this just removes the message about VCE failing to initialize. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197327Reviewed-by:
-
Felix Kuehling authored
memalloc_nofs_save/restore are no longer sufficient to prevent recursive lock warnings when holding locks that can be taken in MMU notifiers. Use memalloc_noreclaim_save/restore instead. Fixes: f920e413 ("mm: track mmu notifiers in fs_reclaim_acquire/release") CC: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Jan Kokemüller authored
dcn21_validate_bandwidth() calls functions that use floating point math. On my machine this sometimes results in simd exceptions when there are other FPU users such as KVM virtual machines running. The screen freezes completely in this case. Wrapping the function with DC_FP_START()/DC_FP_END() seems to solve the problem. This mirrors the approach used for dcn20_validate_bandwidth. Tested on a AMD Ryzen 7 PRO 4750U (Renoir). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206987Signed-off-by:
Jan Kokemüller <jan.kokemueller@gmail.com> Signed-off-by:
-
