- 05 Feb, 2020 9 commits
-
-
Christian König authored
For the root PD mask can be 0xffffffff as well which would overrun to 0 if we don't cast it before we add one. Signed-off-by:
Christian König <christian.koenig@amd.com> Tested-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Make sure that we never allocate a page table for an invalidation operation. Signed-off-by:
-
Christian König authored
The root PD can also contain huge PDEs. Signed-off-by:
-
Christian König authored
We need to update page tables without any lock held. Signed-off-by:
-
Christian König authored
For unlocked page table updates we need to be able to sync to fences of a specific VM. v2: use SYNC_ALWAYS in the UVD code Signed-off-by:
-
Christian König authored
For HMM we need to rework how VM synchronization works, so instead of the filp use VM as job owner. Signed-off-by:
-
Christian König authored
Explicitly sync VM updates to the moving fence in PDs and PTs. Signed-off-by:
-
Lyude Paul authored
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000 RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610 RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000 R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000 R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002 FS: 00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10 R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: * Don't return false when part 1 or part 2 of updating the payloads fails, we don't want to abort at any step of the process even if things fail Reviewed-by:
Mikita Lipski <Mikita.Lipski@amd.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Alex Deucher authored
It needed to be updated as well so it will show the proper values if you reset to the defaults. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
- 04 Feb, 2020 12 commits
-
-
Alex Deucher authored
Cull out 0 clocks to avoid a warning in DC. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
-
Alex Deucher authored
Only send non-0 clocks to DC for validation. This mirrors what the windows driver does. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
-
Alex Deucher authored
We might get different numbers of clocks from powerplay depending on what the OEM has populated. v2: add assert for at least one level Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Alex Deucher authored
Ask the SMU for the default VDDC curve voltage values. This properly reports the VDDC values in the OD interface. v2: only update if the original values are 0 Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Matt Coffin authored
Previously, the syfs functionality for restoring the default powerplay table was sourcing it's information from the currently-staged powerplay table. This patch adds a step to cache the first overdrive table that we see on boot, so that it can be used later to "restore" the powerplay table v2: sqaush my original with Matt's fix Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Signed-off-by:
Matt Coffin <mcoffin13@gmail.com> Reviewed-by:
-
Alex Deucher authored
So users can see the range of valid values. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Alex Deucher authored
You can only adjust the max mclk, not the min. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Bhawanpreet Lakha authored
[Why] When we disable a connector we don't explicitly remove it from the module so the display is still cached(SW) in the hdcp_module. SST: no issues because we can only have 1 display per link MST: We have x displays per link, now if we disable 1 we don't remove it from the module so the module has x display cached(SW). If we try to enable HDCP, psp verification will fail because we are reporting x displays while the HW only has x-1 display enabled [How] Check the callback for when we disable stream and call remove display. Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Mikita Lipski authored
[why] Remove a backslash symbol accidentally left in increase bpp function when computing mst dsc configuration. Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Signed-off-by:
-
Evan Quan authored
This workaround is needed only for Navi10 12 Gbps SKUs. V2: added SMU firmware version guard Signed-off-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
Yong Zhao authored
The sdma_queue_count increment should be done before execute_queues_cpsch(), which calls pm_calc_rlib_size() where sdma_queue_count is used to calculate whether over_subscription is triggered. With the previous code, when a SDMA queue is created, compute_queue_count in pm_calc_rlib_size() is one more than the actual compute queue number, because the queue_count has been incremented while sdma_queue_count has not. This patch fixes that. Signed-off-by:
Yong Zhao <Yong.Zhao@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] In current code we're essentially drawing the cursor on every pipe that contains it. This only works when the planes have the same scaling for src to dest rect, otherwise we'll get "double cursor" where one cursor is incorrectly filtered and offset from the real position. [How] Without dedicated cursor planes on DCN we require at least one pipe that matches the scaling of the current timing. This is an optimization and workaround for the most common case where the top-most plane is not scaled but the bottom-most plane is scaled. Whenever a pipe has a parent pipe in the blending tree whose recout fully contains the current pipe we can disable the pipe. This only applies when the pipe is actually visible of course. Signed-off-by:
-
- 30 Jan, 2020 9 commits
-
-
Alex Deucher authored
Doesn't seem to be used, but add it just in case. Reviewed-by:
-
Nathan Chancellor authored
Clang warns: ../drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c:967:35: warning: implicit conversion from enumeration type 'enum amdgpu_ras_block' to different enumeration type 'enum ta_ras_block' [-Wenum-conversion] block_info.block_id = info->head.block; ~ ~~~~~~~~~~~^~~~~ 1 warning generated. Use the function added in commit 828cfa29 ("drm/amdgpu: Fix amdgpu ras to ta enums conversion") that handles this conversion explicitly. Fixes: 4c461d89 ("drm/amdgpu: add RAS support for the gfx block of Arcturus") Link: https://github.com/ClangBuiltLinux/linux/issues/849Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Daniel Vetter authored
This is an oversight from commit 42585395 Author: Peter Rosin <peda@axentia.se> Date: Thu Jul 13 18:25:36 2017 +0200 drm: radeon: remove dead code and pointless local lut storage v2: Also remove leftover local variable. Cc: Peter Rosin <peda@axentia.se> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Zhan Liu authored
[Why] Need to do atomic check first, then validate global state. If not, when connecting both MST and HDMI displays and set a bad mode via xrandr, system will hang. [How] Move drm_dp_mst_atomic_check() to the front of dc_validate_global_state(). Signed-off-by:
-
Daniel Vetter authored
Per at least one tester this is enough magic to recover the regression introduced for some people (but not all) in commit b8e2b019 Author: Peter Rosin <peda@axentia.se> Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette which for radeon had the side-effect of refactoring out a seemingly redudant writing of the color palette. 10ms in a fairly slow modeset path feels like an acceptable form of duct-tape, so maybe worth a shot and see what sticks. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=198123Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake on the struct field name link_integiry_check, fix this by renaming it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Stephen Rothwell authored
Fixes: 240c811c ("drm/amdgpu: fix VRAM partially encroached issue in GDDR6 memory training(V2)") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Nirmoy Das authored
Currently we pre-allocate entities and fences for all the HW IPs on context creation and some of which are might never be used. This patch tries to resolve entity/fences wastage by creating entity only when needed. v2: allocate memory for entity and fences together Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
-
Joseph Greathouse authored
In previous gfx9 parts, S_BARRIER shader instructions are implicitly S_WAITCNT 0 instructions as well. This setting turns off that mechanism in Arcturus and beyond. With this, shaders must follow the ISA guide insofar as putting in explicit S_WAITCNT operations even after an S_BARRIER. v2: Fix patch title to list component Signed-off-by:
Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by:
-
- 27 Jan, 2020 10 commits
-
-
Colin Ian King authored
There are several spelling mistakes in PP_ASSERT_WITH_CODE messages. Fix these. Signed-off-by:
-
Colin Ian King authored
A for-loop is iterating from 0 up to 1000 however the loop variable count is a u8 and hence not large enough. Fix this by making count an int. Also remove the redundant initialization of count since this is never used and add { } on the loop statement make the loop block clearer. v2: drop useless else (Walter Harms) Addresses-Coverity: ("Operands don't affect result") Fixes: ed581a0a ("drm/amd/display: wait for update when setting dpg test pattern") Signed-off-by: -
Alex Deucher authored
Everything is in place. Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Alex Deucher authored
Has been working fine for a while. Reviewed-by:
-
Dor Askayo authored
This allocation isn't required and can fail when resuming from suspend. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009Signed-off-by:
Dor Askayo <dor.askayo@gmail.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
-
Christian König authored
Coreboot seems to have a problem correctly setting up access to the stolen VRAM on KV/KB. Use the direct access only when necessary. Signed-off-by:
Fredrik Bruhn <fredrik.bruhn@unibap.com> Reviewed-by:
-
Harry Wentland authored
This reverts commit 80adaebd. [WHY] This change was working around a regression that occured in this: commit 0301ccba ("drm/amd/display: DP Compliance 400.1.1 failure") With the fix to run verify_link_cap when the SINK_COUNT of dongles becomes non-zero this change is no longer needed. Cc: Louis Li <Ching-shih.Li@amd.com> Cc: Wenjing Liu <Wenjing.Liu@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Eric Yang <Eric.Yang2@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Signed-off-by:
-
Harry Wentland authored
[WHY] Two years ago the patch referenced by the Fixes tag stopped running dp_verify_link_cap_with_retries during DP detection when the reason for the detection was a short-pulse interrupt. This effectively meant that we were no longer doing the verify_link_cap training on active dongles when their SINK_COUNT changed from 0 to 1. A year ago this was partly remedied with: commit 80adaebd ("drm/amd/display: Don't skip link training for empty dongle") This made sure that we trained the dongle on initial hotplug (without connected downstream devices). This is all fine and dandy if it weren't for the fact that there are some dongles on the market that don't like link training when SINK_COUNT is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately after hotplug, even when a downstream device is connected, and then trigger a shortpulse interrupt indicating a SINK_COUNT change to 1. In order to play nicely we will need our policy to not link train an active DP dongle when SINK_COUNT is 0 but ensure we train it when the SINK_COUNT changes to 1. [HOW] Call dp_verify_link_cap_with_retries on detection even when the detection is triggered from a short pulse interrupt. With this change we can also revert this commit which we'll do in a separate follow-up change: commit 80adaebd ("drm/amd/display: Don't skip link training for empty dongle") Fixes: 0301ccba ("drm/amd/display: DP Compliance 400.1.1 failure") Suggested-by:
Louis Li <Ching-shih.Li@amd.com> Tested-by:
-
Alex Deucher authored
So don't use it. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Alex Deucher authored
Switch to a blacklist so we can disable specific boards that are problematic. v2: make the blacklist non-raven specific. Reviewed-by:
-
