- Feb 07, 2020
-
-
Nicholas Kazlauskas authored
[Why] The General Purpose Interrupt is used on the DMCUB to pass lightweight commands via a register to the DMCUB. This is limited to 32-bit command and 32-bit response. This will be used for shutting down the firmware in a clean manner. [How] Add the command IDs and the data register to correctly format the commands. Add the interface functions to dmub_srv for sending and receiving the commands. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Eric Bernstein authored
[Why] Diagnostics team reported various issues found when enabling warnings as errors [How] Fix implicit conversions Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Anthony Koo authored
[Why] DSC updates only set type to FULL UPDATE, but doesn't flag the change [How] Add DSC flag update flag Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
-
Anthony Koo authored
[Why] Eventually want to lock at a higher level in stack. To do this, we need to be able to isolate the parts that need to be done after pipe unlock. [How] Split out programming that is done post unlock. Signed-off-by:
-
Sung Lee authored
[WHY] The optimized_require flag is needed to set watermarks and clocks lower in certain conditions. This flag is set to true and then set to false while programming front end in dcn20. [HOW] Do not set the flag to false while disabling plane. Signed-off-by:
Sung Lee <sung.lee@amd.com> Reviewed-by:
-
Roman Li authored
[Why] Driver crash with psr feature enabled due to divide-by-zero error. This is a regression after rework to calculate static screen frame number entry time. [How] Correct order of operations to avoid divide-by-zero. Signed-off-by:
Roman Li <roman.li@amd.com> Reviewed-by:
Zhan Liu <Zhan.Liu@amd.com> Acked-by:
-
Joseph Gravenor authored
[why/how] We found out that the register we read actually gets reset by SMU after we loose power, meaning this always returns true Signed-off-by:
Joseph Gravenor <joseph.gravenor@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
George Shen authored
[Why] The call to dp_enable_link_phy are using default/invalid values for clock id and link settings. [How] Move workaround code to after its parameter variables are determined. Signed-off-by:
George Shen <george.shen@amd.com> Reviewed-by:
-
Wyatt Wood authored
[Why] Must know psr version during runtime. [How] Add set psr version message structures. Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
-
Hawking Zhang authored
For sriov, psp ip block has to be initialized before ih block for the dynamic register programming interface that needed for vf ih ring buffer. On the other hand, current psp ip block hw_init function will initialize xgmi session which actaully depends on interrupt to return session context. This results an empty xgmi ta session id and later failures on all the xgmi ta cmd invoked from vf. xgmi ta session initialization has to be done after ih ip block hw_init call. to unify xgmi session init/fini for both bare-metal sriov virtualization use scenario, move xgmi ta init to xgmi_add_device call, and accordingly terminate xgmi ta session in xgmi_remove_device call. The existing suspend/resume sequence will not be changed. v2: squash in return fix from Nirmoy Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
Frank Min <Frank.Min@amd.com> Signed-off-by:
-
Bhawanpreet Lakha authored
Call the cmd ids for set/get srm according to the sysfs call v2: Use define for the magic number Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] we need to load SRM before we start HDCP. Because for S3 case the sysfs call will be after we have already enabled HDCP, so we might not be using the latest SRM [How] Set srm before starting HDCP. Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] PSP doesn't have the ability to store SRM in a non-volatile memory. And since the kernel cannot write to the storage directly, we need usermode to facilitate this As per spec the SRM needs to be persistent so this interface is to be called by the usermode anytime the system goes down/powers on *boot/resume: load from storage *shutdown/suspend: save to storage [How] Provide a sysfs interface so that the usermode can set/get srm at the right times save to storage: call "cat /sys/class/drm/card0/device/hdcp_srm > file" after boot and resume -driver calls psp_get_srm() to get the stored srm and outputs it load from storage: call "cat file > /sys/class/drm/card0/device/hdcp_srm" before shutdown and suspend -driver reads the file from sysfs and calls psp_set_srm() to send the SRM to PSP v2: -update commit description -add comment about sysfs file handling in the code v3: - squash in use after free fix (Dan Carpenter) Signed-off-by:
-
- Feb 05, 2020
-
-
Bhawanpreet Lakha authored
[Why] We need to support SRM(System Renewability Message) As per hdcp spec (5.Renewability) SRM needs to be storage in a non-volatile memory. PSP owns the checking of SRM but doesn't have the ability to store it in a non-volatile memory. So we need the kernel driver to facilitate it using the interface provided by PSP [How] Add the interface to the header file, so the driver can use them v2: update commit description Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] We need this to create sysfs (followup patch) [How] Change the parameter Signed-off-by:
-
Christian König authored
If provided we only sync to the BOs reservation object and no longer to the root PD. v2: update comment, cleanup amdgpu_bo_sync_wait_resv v3: use correct reservation object while clearing v4: fix typo in amdgpu_bo_sync_wait_resv 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:
-
Christian König authored
No matter what we always need to sync to moves. Signed-off-by:
-
Christian König authored
Allow partial invalidation on unallocated PDs. This is useful when we need to silence faults to stop interrupt floods on Vega. Signed-off-by:
-
Christian König authored
That we can't find a PD above the root is expected can only happen if we try to update a larger range than actually managed by the VM. Signed-off-by:
-
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 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:
-
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/1020 Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
- Feb 04, 2020
-
-
Alex Deucher authored
Cull out 0 clocks to avoid a warning in DC. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-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/963 Reviewed-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/963 Reviewed-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/1020 Reviewed-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/1020 Signed-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/1020 Reviewed-by:
-
Alex Deucher authored
You can only adjust the max mclk, not the min. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-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:
-
Mikita Lipski authored
[why] Remove a backslash symbol accidentally left in increase bpp function when computing mst dsc configuration. 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:
-
