- 13 Apr, 2020 11 commits
-
-
Alex Deucher authored
We don't want a GPU scheduler for this ring. Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
This allows IPs to flag whether a specific ring requires a GPU scheduler or not. E.g., sometimes instances of an IP are asymmetric and have different capabilities. Reviewed-by:
-
Likun Gao authored
Get SMC fw size before backdoor loading instead of giving an certain value, as it may different for different ASIC. Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Evan Quan authored
Vram lost counter is wrongly increased by two during baco reset. V2: assumed vram lost for mode1 reset on all ASICs Signed-off-by:
-
Guchun Chen authored
Prefix RAS message printing in GFX IP with PCI device info, which assists the debug in multiple GPU case. Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
-
Yintian Tao authored
If there is no GPU hang, user still can access debugfs through kiq. Signed-off-by:
Yintian Tao <yttao@amd.com> Reviewed-by:
Monk Liu <Monk.liu@amd.com> Signed-off-by:
-
Guchun Chen authored
Prefix ras related kernel message logging with PCI device info by replacing DRM_INFO/WARN/ERROR with dev_info/warn/err. This can clearly tell user about GPU device information where ras is. And add some other ras message printing to make it more clear and friendly as well. Suggested-by:
-
Guchun Chen authored
Uncorrectable error count printing is missed when issuing UMC UE injection. When going to the error count log function in GPU recover work thread, there is no chance to get correct error count value by last error injection and print, because the error status register is automatically cleared after reading in UMC ecc irq callback. So add such message printing in UMC ecc irq cb to be consistent with other RAS error interrupt cases. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Sergei Lopatin authored
Should prevent flicker if PP_OVERDRIVE_MASK is set. bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646 bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628Signed-off-by:
Sergei Lopatin <magist3r@gmail.com> Signed-off-by:
-
Zhan Liu authored
[Why] If reading dpcd happens ahead of hw initialization, then aconnector is NULL at this point. This is expected, so there is no need to output an error (which will spam dmesg.log) [How] Change type of message from "error" to "DC_LOG_DC". Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
-
Yintian Tao authored
Under bare metal, there is no more else to take care of the GPU register access through MMIO. Under Virtualization, to access GPU register is implemented through KIQ during run-time due to world-switch. Therefore, under SR-IOV user can only access debugfs to r/w GPU registers when meets all three conditions below. - amdgpu_gpu_recovery=0 - TDR happened - in_gpu_reset=0 v2: merge amdgpu_virt_can_access_debugfs() into amdgpu_virt_enable_access_debugfs() v3: drop ret variable in amdgpu_virt_enable_access_debugfs() and directly return result Signed-off-by:
-
- 09 Apr, 2020 29 commits
-
-
John Clements authored
added macro to define timeout Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Evan Quan authored
This sequence is recommended by PMFW team for the baco reset with PMFW reloaded. And it seems able to address the random failure seen on Arcturus. Signed-off-by:
Feifei Xu <Feifei.Xu@amd.com> Reviewed-by:
-
Aurabindo Pillai authored
Execution will only reach here if the asserted condition is true. Hence there is no need for the additional check. Signed-off-by:
Aurabindo Pillai <mail@aurabindo.in> Signed-off-by:
-
Alex Deucher authored
fixes unused variable warning. Reported-by:
Eric Biggers <ebiggers@kernel.org> Acked-by:
Mikita Lipski <mikita.lipski@amd.com> Signed-off-by:
-
Aaron Liu authored
Make the fw_write_wait default case true since presumably all new gfx9 asics will have updated firmware. That is using unique WAIT_REG_MEM packet with opration=1. Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Tested-by:
Yuxian Dai <Yuxian.Dai@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Hawking Zhang authored
add indirect access support to registers outside of mmio bar. Signed-off-by:
-
Hawking Zhang authored
all the register access through kiq is redirected to amdgpu_kiq_rreg/amdgpu_kiq_wreg Signed-off-by:
-
Hawking Zhang authored
those are not needed anymore Signed-off-by:
-
Hawking Zhang authored
not needed anymore Signed-off-by:
-
Hawking Zhang authored
all the mmCUR_CONTROL instances are in mmr range and can be accessd directly by using RREG32/WREG32 Signed-off-by:
-
Hawking Zhang authored
the workaround is not needed for soc15 ASICs except for vega10. it is even not needed with latest vega10 vbios. Signed-off-by:
-
Evan Quan authored
For Arcturus, forcing clock to some specific level is not supported with 54.18 and onwards SMU firmware. As according to firmware team, they adopt new gfx dpm tuned parameters which can cover all the use case in a much smooth way. Thus setting through driver interface is not needed and maybe do a disservice. Signed-off-by:
-
Prike Liang authored
The system will be hang up during S3 suspend because of SMU is pending for GC not respose the register CP_HQD_ACTIVE access request.This issue root cause of accessing the GC register under enter GFX CGGPG and can be fixed by disable GFX CGPG before perform suspend. v2: Use disable the GFX CGPG instead of RLC safe mode guard. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Tested-by:
Mengbing Wang <Mengbing.Wang@amd.com> Reviewed-by:
-
Bhawanpreet Lakha authored
Add debugfs to get HDCP capability. This is also useful for kms_content_protection igt test. Use: cat /sys/kernel/debug/dri/0/DP-1/hdcp_sink_capability cat /sys/kernel/debug/dri/0/HDMI-A-1/hdcp_sink_capability Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by:
-
Bhawanpreet Lakha authored
[Why] Query the hdcp caps of a link, it is useful and can be reported to the user [How] Create a query function and call it during link detect Signed-off-by:
-
Kent Russell authored
There is at least 1 VG20 DID that does not have an FRU, and trying to read that will cause a hang. For now, explicitly support reading the FRU for Arcturus and for the WKS VG20 DIDs, and skip for everything else. This re-enables serial number reporting for server cards v2: Add ASIC check v3: Don't default to true for pre-VG20 v4: Use DID instead of parsing the VBIOS v5: Sqaush in overflow warning fix Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] By moving everything out of .data into the other regions we can drop the requirement for the second blob and unify it all into the inst/const blob. [How] We need to still support the blob being there and not being there for backwards compatibility. Look for the DMCUB metadata section in the end of the inst/const blob instead of bss/data is missing. Clear CW2 if we don't have the data blob so we don't hang when transitioning between data blob/blobless firmwares. Don't memcpy the blob into CW2 region if it doesn't exist. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Wenjing Liu authored
[why] When display is connected with a native DP port, DP2 mode register value is a don't care. Driver mistakenly reduce max supported lane count to 2 lane based on the don't care value. [how] Add additional check only if USB C DP alt mode is enabled, we will determine max lane count supported based on current mode. Signed-off-by:
Wenjing Liu <wenjing.liu@amd.com> Reviewed-by:
-
Michael Strauss authored
[WHY] In cases where a clock table is malformed such that fclk entries have frequencies but not voltages listed, we don't catch the error and set clocks to 0 instead of using hardcoded values as we should. [HOW] Add check for clock tables fclk entry's voltage as well Signed-off-by:
Michael Strauss <michael.strauss@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Joshua Aberback authored
[Why] If dc->clk_mgr->funcs->are_clock_states_equal is set, then wm_optimized_required is never checked. In that case, when going from a higher mode to a lower mode, wm_optimized_required remains true until the next mode change. [How] - move from else-if to unconditional or Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
Yongqiang Sun <yongqiang.sun@amd.com> Acked-by:
-
Jaehyun Chung authored
[Why] In most cases, DRAM watermark is large enough that the result of the condition to increase TTU doesn't change after DRAM watermark is increased. However, there is are cases where the condition fails and becomes true after DRAM watermark is increased. This results in minTTU < DRAM watermarks which leads to PSR hang since p-state is requested but not allowed. [How] Check whether to update TTU after DRAM watermark is updated. Signed-off-by:
Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by:
-
Jerry (Fangzhi) Zuo authored
[Why] Prop are created at boot stage, and not allowed to create new prop after device registration. [How] Reuse the connector property from SST if exist. Signed-off-by:
Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] In some usecases, like tiled display, the stream and plane configuration can be setup in a way where the caller expects DAL to perform the clipping, eg: P0: src_rect(0, 0, w, h) dst_rect(0, 0, w, h) P1: src_rect(w, 0, w, h) dst_rect(0, 0, w, h) Cursor is enabled on both streams with the same position. This can result in double cursor on tiled display, even though this behavior is technically correct from the DC interface point of view. We need a mechanism to control this dynamically. [How] This is something that should live in the DM layer based on detection of the specified configuration but it's not something that we really have enough information to deal with today. Add a flag to the cursor position state that specifies whether we want DC to do the translation or not and make it opt-in and let the DM decide when to do it. Signed-off-by:
-
Alvin Lee authored
[Why] New formula + cursor change causing underflow on certain configs [How] Rever to old formula Signed-off-by:
Alvin Lee <alvin.lee2@amd.com> Reviewed-by:
-
Stylon Wang authored
[Why] - In amdgpu_dm_update_plane_color_mgmt() it is inconsistent in taking in dm_crtc_state and dc_plane_state. - Makes supporting plane-level color management with proper guard more complicated than necessary. [How] Pass in dm_plane_state in place of dc_plane_state in amdgpu_dm_update_plane_color_mgmt(). Signed-off-by:
Stylon Wang <stylon.wang@amd.com> Reviewed-by:
-
Charlene Liu authored
[why] usb3->usb2 switch system hang. driver needs to limit the max sink cap based on DP4 mode. [how] based on s_dpalt check and DP4 check: limit the USB-C DPALT DP maximum supported lane count. Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Dmytro Laktyushkin authored
Dml merges mpc/odm combine pipes to do calculations. This merge is imperfect if there is a viewport overlap. This change saves pre overlap viewport for dml use. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by:
-
Isabel Zhang authored
[Why] After v_total_min and max are updated in vrr structure, the changes are not reflected in stream adjust. When these values are read from stream adjust it does not reflect the actual state of the system. [How] Set stream adjust values equal to vrr adjust values after vrr adjust values are updated. Signed-off-by:
Isabel Zhang <isabel.zhang@amd.com> Reviewed-by:
-
