- 02 Feb, 2022 33 commits
-
-
Christian König authored
We ran into the problem that clearing really larger buffer (60GiB) caused an SDMA timeout. Restructure the function to use the dst window instead of mapping the whole buffer into the GART and then fill only 2MiB/256MiB chunks at a time. v2: rebase on restructured window map. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Instead of limiting the size before we call the mapping function let the function itself limit the size. Signed-off-by:
-
Christian König authored
That should never happen, but make sure that we only warn instead of crash. Signed-off-by:
-
Christian König authored
We probably never trigger this, but the logic inside the check is inverted. Signed-off-by:
-
Aun-Ali Zaidi authored
The eDP link rate reported by the DP_MAX_LINK_RATE dpcd register (0xa) is contradictory to the highest rate supported reported by EDID (0xc = LINK_RATE_RBR2). The effects of this compounded with commit '4a8ca46b ("drm/amd/display: Default max bpc to 16 for eDP")' results in no display modes being found and a dark panel. For now, simply force the maximum supported link rate for the eDP attached 2018 15" Apple Retina panels. Additionally, we must also check the firmware revision since the device ID reported by the DPCD is identical to that of the more capable 16,1, incorrectly quirking it. We also use said firmware check to quirk the refreshed 15,1 models with Vega graphics as they use a slightly newer firmware version. Tested-by:
Aun-Ali Zaidi <admin@kodeit.net> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Aditya Garg <gargaditya08@live.com> Signed-off-by:
-
Yang Li authored
Eliminate the follow smatch warning: drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c:2246 dp_perform_8b_10b_link_training() warn: inconsistent indenting Reviewed-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Fangzhi Zuo authored
DP2 sequence is triggered only if VESA certified cable is detected. Force DP2 sequence with uncertified cable for testing purpose. Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
Stylon Wang <stylon.wang@amd.com> Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by:
-
Aric Cyr authored
This version brings along following fixes: - DC refactor and bug fixes for DP links - Bug fixes for DP2 - Fix regressions causing display not light up - Improved debug trace - Improved DP AUX transfer - Updated watermark latencies to fix underflows in some modes Tested-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
Anthony Koo authored
- Correct number of reserved bits in cmd_lock_hw - Extend bits of hw_lock_client to allow for more clients Tested-by:
Anthony Koo <Anthony.Koo@amd.com> Signed-off-by:
-
Wenjing Liu authored
[why] Move link_hwss to its own folder as part of DC LIB and break it down to separate file one for each type of backend for code isolation. Tested-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
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:
-
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:
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:
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:
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 6 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:
-
