- 02 Feb, 2022 23 commits
-
-
Wenjing Liu authored
[why] Isolate the way to obtain link_hwss from the actual implemenation of link_hwss. So the caller can call link_hwss without knowing the implementation detail of link_hwss. Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Stylon Wang <stylon.wang@amd.com> Signed-off-by:
Wenjing Liu <wenjing.liu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Wenjing Liu authored
[why] Clean up dc_link_hwss file in the preparation of breaking it down to file for each encoder type. We temporarly move the original dp link functions in link_hwss back to dc_link_dp. We will break dc_link_dp down after link_hwss is in good shape. Tested-by:
-
Wenjing Liu authored
[why] Factor set dp lane settings to link_hwss. v2: fix statement with no effect warning (Alex) Tested-by:
-
Wenjing Liu authored
[why] Factor set dp link test pattern to link_hwss. Tested-by:
-
Wenjing Liu authored
[why] Factor enable/disable dp link output to link hwss. Tested-by:
Wayne Lin <wayne.lin@amd.com> Signed-off-by:
-
Wenjing Liu authored
[how] 1. move decide det link training link resource before each link training. 2. move disable link for handling vbios case into set all streams dpms off for link sequence. 3. extract usbc hotplug workaround into its own wa function. 4. Minor syntax changes to improve code readability. Tested-by:
-
Wenjing Liu authored
[why] Factor setup/reset stream encoder to link hwss. Tested-by:
-
Zhan Liu authored
[Why] This change causes regression, that prevents some systems from lighting up internal displays. [How] Revert this patch until a new solution is ready. Tested-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
Zhan Liu <Zhan.Liu@amd.com> Signed-off-by:
-
Leo (Hanghong) Ma authored
[Why] We find some of the driver sequence debug trace for infoframe update is missing so add it. [How] Add the missing sequence debug trace for infoframe update. Tested-by:
Martin Leung <Martin.Leung@amd.com> Acked-by:
Leo (Hanghong) Ma <hanghong.ma@amd.com> Signed-off-by:
-
Paul Hsieh authored
[Why] The original latencies were causing underflow in some modes. Resolution: 2880x1620@60p when HDR enable [How] 1. Replace with the up-to-date watermark values based on new measurments 2. Correct the ddr_wm_table name to DDR5 on DCN31 Tested-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Paul Hsieh <paul.hsieh@amd.com> Signed-off-by:
-
Wyatt Wood authored
[Why + How] Payload reply is unknown and not handled in switch statement. Tested-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Wyatt Wood <wyatt.wood@amd.com> Signed-off-by:
-
Shen, George authored
[Why] Certain configurations will result in link encoder to not be assigned to the link at the time we apply cable ID logic. We should skip it in those cases. [How] Check if link_enc is not null before applying cable ID. Tested-by:
George Shen <george.shen@amd.com> Signed-off-by:
-
Guchun Chen authored
A lot of below message are outputed in SRIOV case. amdgpu: indirect registers access through rlcg is not supported Also drop redundant ret set, as it's initialized to be false already. Fixes: 29dbcac8 ("drm/amdgpu: add helper to query rlcg reg access flag") Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Acked-by:
-
Lijo Lazar authored
Fix uninitialized variable use warning: variable 'reg_access_ctrl' is uninitialized when used here [-Wuninitialized] scratch_reg0 = (void __iomem *)adev->rmmio + 4 * reg_access_ctrl->scratch_reg0; Fixes: 5d447e29 ("drm/amdgpu: add helper for rlcg indirect reg access") Reported-by:kernel test robot <yujie.liu@intel.com> Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
-
yipechai authored
1. The infinite loop causing soft lock occurs on multiple amdgpu cards supporting ras feature. 2. This a workaround patch to fix 6492e1b0. It is valid for multiple amdgpu cards of the same type. 3. The root cause is that each GPU card device has a separate .ras_list link header, but the instance and linked list node of each ras block are unique. When each device is initialized, each ras instance will repeatedly add link node to the device every time. In this way, only the .ras_list of the last initialized device is completely correct. the .ras_list->prev and .ras_list->next of the device initialzied before can still point to the correct ras instance, but the prev pointer and next pointer of the pointed ras instance both point to the last initialized device's .ras_ list instead of the beginning .ras_ list. When using list_for_each_entry_safe searches for non-existent Ras nodes on devices other than the last device, the last ras instance next pointer cannot always be equal to the beginning .ras_list, so that the loop cannot be terminated, the program enters a infinite loop. BTW: Since the data and initialization process of each card are the same, the link list between ras instances will not be destroyed every time the device is initialized. 4. The soft locked logs are as follows: [ 262.165690] CPU: 93 PID: 758 Comm: kworker/93:1 Tainted: G OE 5.13.0-27-generic #29~20.04.1-Ubuntu [ 262.165695] Hardware name: Supermicro AS -4124GS-TNR/H12DSG-O-CPU, BIOS T20200717143848 07/17/2020 [ 262.165698] Workqueue: events amdgpu_ras_do_recovery [amdgpu] [ 262.165980] RIP: 0010:amdgpu_ras_get_ras_block+0x86/0xd0 [amdgpu] [ 262.166239] Code: 68 d8 4c 8d 71 d8 48 39 c3 74 54 49 8b 45 38 48 85 c0 74 32 44 89 fa 44 89 e6 4c 89 ef e8 82 e4 9b dc 85 c0 74 3c 49 8b 46 28 <49> 8d 56 28 4d 89 f5 48 83 e8 28 48 39 d3 74 25 49 89 c6 49 8b 45 [ 262.166243] RSP: 0018:ffffac908fa87d80 EFLAGS: 00000202 [ 262.166247] RAX: ffffffffc1394248 RBX: ffff91e4ab8d6e20 RCX: ffffffffc1394248 [ 262.166249] RDX: ffff91e4aa356e20 RSI: 000000000000000e RDI: ffff91e4ab8c0000 [ 262.166252] RBP: ffffac908fa87da8 R08: 0000000000000007 R09: 0000000000000001 [ 262.166254] R10: ffff91e4930b64ec R11: 0000000000000000 R12: 000000000000000e [ 262.166256] R13: ffff91e4aa356df8 R14: ffffffffc1394320 R15: 0000000000000003 [ 262.166258] FS: 0000000000000000(0000) GS:ffff92238fb40000(0000) knlGS:0000000000000000 [ 262.166261] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 262.166264] CR2: 00000001004865d0 CR3: 000000406d796000 CR4: 0000000000350ee0 [ 262.166267] Call Trace: [ 262.166272] amdgpu_ras_do_recovery+0x130/0x290 [amdgpu] [ 262.166529] ? psi_task_switch+0xd2/0x250 [ 262.166537] ? __switch_to+0x11d/0x460 [ 262.166542] ? __switch_to_asm+0x36/0x70 [ 262.166549] process_one_work+0x220/0x3c0 [ 262.166556] worker_thread+0x4d/0x3f0 [ 262.166560] ? process_one_work+0x3c0/0x3c0 [ 262.166563] kthread+0x12b/0x150 [ 262.166568] ? set_kthread_struct+0x40/0x40 [ 262.166571] ret_from_fork+0x22/0x30 Fixes: 6492e1b0 ("drm/amdgpu: Unify ras block interface for each ras block") Signed-off-by:
yipechai <YiPeng.Chai@amd.com> Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Agustin Gutierrez authored
[Why] There is underflow / visual corruption DCN301, for high bandwidth MST DSC configurations such as 2x1440p144 or 2x4k60. [How] Use up-to-date watermark values for DCN301. Reviewed-by:
Agustin Gutierrez <agustin.gutierrez@amd.com> Signed-off-by:
-
Philip Yang authored
All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function 'svm_range_deferred_list_work': >> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:2067:22: warning: variable 'p' set but not used [-Wunused-but-set-variable] 2067 | struct kfd_process *p; | Fixes: 367c9b0f ("drm/amdkfd: Ensure mm remain valid in svm deferred_list work") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-By:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by:
-
Colin Ian King authored
There are quite a few spelling mistakes in various function names and error messages. Fix these. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Changcheng Deng authored
'amdgpu_dpm.h' included in 'arcturus_ppt.c' is duplicated. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by:
-
Changcheng Deng authored
'linux/pci.h' included in 'amdgpu_device.c' is duplicated. Reported-by:
-
Lang Yu authored
We observed a GPU hang when querying GMC CG state(i.e., cat amdgpu_pm_info) on cyan skillfish. Acctually, cyan skillfish doesn't support any CG features. Just prevent it from accessing GMC CG registers. Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
-
Mario Limonciello authored
This will cause misconfigured systems to not run the GPU suspend routines. * In APUs that are properly configured system will go into s2idle. * In APUs that are intended to be S3 but user selects s2idle the GPU will stay fully powered for the suspend. * In APUs that are intended to be s2idle and system misconfigured the GPU will stay fully powered for the suspend. * In systems that are intended to be s2idle, but AMD dGPU is also present, the dGPU will go through S3 Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
-
Mario Limonciello authored
This will be used to help make decisions on what to do in misconfigured systems. v2: squash in semicolon fix from Stephen Rothwell Signed-off-by:
-
- 31 Jan, 2022 1 commit
-
-
Mario Limonciello authored
On some OEM setups users can configure the BIOS for S3 or S2idle. When configured to S3 users can still choose 's2idle' in the kernel by using `/sys/power/mem_sleep`. Before commit 6dc8265f ("drm/amdgpu: always reset the asic in suspend (v2)"), the GPU would crash. Now when configured this way, the system should resume but will use more power. As such, adjust the `amdpu_acpi_is_s0ix function` to warn users about potential power consumption issues during their first attempt at suspending. Reported-by:
Bjoren Dasse <bjoern.daase@gmail.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1824Reviewed-by:
-
- 27 Jan, 2022 16 commits
-
-
huangqu authored
Wrong order for config and counter_id parameters was passed, when calling df_v3_6_pmc_set_deferred and df_v3_6_pmc_is_deferred functions. Signed-off-by:
huangqu <jinsdb@126.com> Signed-off-by:
-
tangmeng authored
There is a spelling mistake. Fix it. Signed-off-by:
tangmeng <tangmeng@uniontech.com> Signed-off-by:
-
Alex Deucher authored
So mesa and tools know when this is available. Mesa MR: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/207Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Alex Deucher authored
Add a new CTX ioctl operation to set stable pstates for profiling. When creating traces for tools like RGP or using SPM or doing performance profiling, it's required to enable a special stable profiling power state on the GPU. These profiling states set fixed clocks and disable certain other power features like powergating which may impact the results. Historically, these profiling pstates were enabled via sysfs, but this adds an interface to enable it via the CTX ioctl from the application. Since the power state is global only one application can set it at a time, so if multiple applications try and use it only the first will get it, the ioctl will return -EBUSY for others. The sysfs interface will override whatever has been set by this interface. Mesa MR: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/207 v2: don't default r = 0; v3: rebase on Evan's PM cleanup Reviewed-by:
-
Alex Deucher authored
Return an error if someone tries to use the i2c bus when the SMU is not running. Otherwise we can end up sending commands to the SMU which will either get ignored or could cause other issues depending on what state the GPU and SMU are in. Cc: Luben.Tuikov@amd.com Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Luben Tuikov authored
Enable the FRU EEPROM I2C bus for Sienna Cichlid server boards, for which it is enabled by checking the VBIOS version. Cc: Roy Sun <Roy.Sun@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by:
-
Luben Tuikov authored
Expose both SMU I2C buses. Some boards use the same bus for both the RAS and FRU EEPROMs and others use different buses. This enables the additional I2C bus and sets the right buses to use for RAS and FRU EEPROM access. Cc: Roy Sun <Roy.Sun@amd.com> Co-developed-by:
-
Aaron Liu authored
This patch adds 1.3.1/2.4.0 athub clock gating support. Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Aaron Liu authored
Use IP version rather than codename for athub. Signed-off-by:
-
Tim Huang authored
[Why] It will build failed with unused variable 'dc' with '-Werror=unused-variable'enabled when CONFIG_DRM_AMD_DC_DCN is not defined. Signed-off-by:
Tim Huang <tim.huang@amd.com> Reviewed-by:
-
Tao Zhou authored
On ALDEBARAN, the umc channel bits are not original values, they are hashed. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Tao Zhou authored
On ALDEBARAN, we need to traverse all column bits higher than BIT11(C4C3C2) in a row, the shift of R14 bit should be also taken into account. Retire all pages we find. Signed-off-by:
-
Tao Zhou authored
One piece of umc normalizing address can be mapped to 16 pieces of physical address in each umc channel on ALDEBARAN. Signed-off-by:
-
Tao Zhou authored
Create common amdgpu_umc_fill_error_record function for all versions of UMC and clean up related codes. Signed-off-by:
-
Mario Limonciello authored
A number of BIOS versions have a problem with the watermarks table not being configured properly. This manifests as a very scary looking warning during resume from s0i3. This should be harmless in most cases and is well understood, so decrease the assertion to a clearer warning about the problem. Reviewed-by:
-
Felix Kuehling authored
On GPUs with RAS, poison can propagate between processes if VRAM is not cleared when it is freed or allocated. The reason is, that not all write accesses clear RAS poison. 32-byte writes by the SDMA engine do clear RAS poison. Clearing memory in the background when it is freed should avoid major performance impact. KFD has been doing this already for a long time. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
