- 09 Apr, 2020 40 commits
-
-
Hawking Zhang authored
not needed anymore Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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 <Hawking.Zhang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Hawking Zhang <Hawking.Zhang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Aric Cyr authored
Signed-off-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Tony Cheng <Tony.Cheng@amd.com> Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
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: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Aric Cyr authored
Signed-off-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Wyatt Wood authored
[Why] Defines aren't used. Remove them. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] If a plane isn't being actively enabled or disabled then DC won't always recalculate scaling rects and ratios for the primary plane. This results in only a partial or corrupted rect being displayed on the screen instead of scaling to fit the screen. [How] Add back the logic to recalculate the scaling rects into dc_commit_updates_for_stream since this is the expected place to do it in DC. This was previously removed a few years ago to fix an underscan issue but underscan is still functional now with this change - and it should be, since this is only updating to the latest plane state getting passed in. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] For medium updates that change nothing but the source rect position the viewport doesn't change on DCN20. We're missing the check for the position update bit that was there in the DCN10 hardware sequencer. [How] Check the position bit along with the scaling bit like we were doing with DCN20. We shouldn't actually hit a case where context != current_state in our programming/commit model but guard against it anyway since it was guarded for the other bits. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] Cursor pos is correctly adjusted from DC side for source rect offset on DCN ASIC, but only on the overlay. This is because DM places offsets the cursor for primary planes only to workaround missing code in DCE for the adjustment we're now correctly doing in DC for DCN ASIC. [How] Drop the adjustment for source rect from the DM side of things and put the code where it actually belongs - in DC on the pipe level. This matches what we do for DCN now. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Eric Yang authored
[Why] Changing policy to dynamic will allow 4k multi display configs to be supported at DPM0 Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] Cursor is drawn as part of the framebuffer for a plane on AMD hardware. The cursor position on the framebuffer does not change even if the source rect viewport for the cursor does. This causes the cursor to be clipped. The following IGT tests fail as a result of this issue: - kms_plane_cursor@pipe-*-viewport-size-* [How] Offset cursor position by plane source rect viewport. If the viewport is unscaled then the cursor is now correctly positioned on any plane - primary or overlay. There is still a hardware limitation for dealing with the cursor size being incorrectly scaled but that's not something we can address. Add some documentation explaining some of this in the code while we're at it. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Wyatt Wood authored
Decouple dmcub config copy from dmcu iram copy. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Xiaodong Yan authored
[why] blank all dp stream would impact edp [how] only blank the one which will be powered off Signed-off-by: Xiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Joseph Gravenor authored
[why] MOD_HDCP_STATUS_HDCP1_ENABLE_ENCRYPTION and MOD_HDCP_STATUS_HDCP2_ENABLE_ENCRYPTION were supposed to be MOD_HDCP_STATUS_HDCP1_ENABLE_ENCRYPTION_FAILURE and MOD_HDCP_STATUS_HDCP2_ENABLE_ENCRYPTION_FAILURE. Because of this it always seems like mod_hdcp_hdcp1_enable_encryption and mod_hdcp_hdcp2_enable_encryption are always passing [how] rename the elements to what they were supposed to be called Signed-off-by: Joseph Gravenor <joseph.gravenor@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Wyatt Wood authored
[Why] When dmcub is the default we no longer wish to create the psr and dmcu objects. Currently a dc debug flag is used to implement this, but these flags aren't populated until after dcn21_resource_construct is called. This means the dmcub objects will never be created. Therefore we must use a dc config flag, which is populated before dc resource construct. [How] Add a dc config flag. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Sung Lee authored
[WHY] The power_down() function was only defined for specific asics and will crash the system if it is called by an asic with eDP connected that does not have it defined. [HOW] Add a check for the function's existence before calling it. Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] Overlay planes disappear when the plane's alpha blending mode or global opacity is modified. These are considered UPDATE_TYPE_MEDIUM and trigger the update_mpcc path in the DCN hardware sequencer. On DCN10 we have an "optimization" to avoid touching the blending tree on these updates, but this is actually required behavior based on how update_mpcc is structured. For full updates we acquire a MPCC for the plane, remove it if it already exists then reinsert it after with insert_plane. The call to insert_plane can take an optional mpcc to insert the new one above to preserve the current blending order. The update_mpcc hwseq function doesn't do this so the overlay gets sent to the very bottom of the tree. [How] Copy the check over from DCN10 to DCN20. The only time we need to actually touch the tree really is the full update, so this is also an optimization on top of the fix. Fixing the logic for insert_plane is rather simple (cache the bot_mpcc and pass it to insert_plane) but is a change that impacts most display usecases. For now stick with the optimization. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Xiaodong Yan authored
[why] power off dp receiver directly cause garbage during hw init [how] blank dp stream and then power off receiver Signed-off-by: Xiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Sung Lee authored
[WHY] On headless boot a DIG may be turned on by VBIOS on RN. This leads to display_count being non-zero in hybrid graphics cases leading to SMU DISPLAY_OFF message not being sent. [HOW] Power down hardware on boot if seamless boot is not occurring (power_down_display_on_boot == 1) Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Isabel Zhang authored
[Why] Due to previous code changes, displays transition from active to active and added state immediately, making it redundant to have both display states. Previous change to fix this caused HDCP to get into a bad state when monitor is connected to MST hub, this change fixes that issue. [How] Change code behavior so when a device is added successfully the state remains as active and when addition is unsuccessful change state to inactive. This removes need for added and active state. Signed-off-by: Isabel Zhang <isabel.zhang@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Wyatt Wood authored
[Why] Driver must pass abm config table to dmub fw. This provides various parameters for abm functionality. [How] There is too much data to be passed in an inbox message, so we must pass this data using an indirect buffer. Copy the table to cw7 via x86, driver copies to fw_state structure. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Nikola Cornij authored
[why] Link or DIG BE can't be exposed to a higher stream bandwidth than they can handle. When DSC is required to fit the stream into the link bandwidth, DSC has to be programmed before the link is enabled to ensure this. Without it, intermittent issues such as black screen after S3 or a hot-plug can be seen with DSC timings like 4k144Hz or 8k60Hz. [how] Move DSC programming from before enabling stream to before enabling link Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Josip Pavic authored
[Why] If no free pipes are available, acquire_first_split_pipe is called to get a pipe to use. This call may alter the ordering of the pipes in the list so that, for example, the tail pipe changes. If acquire_first_split_pipe returns the tail pipe, we'll have free_pipe == tail_pipe. What tail_pipe refers to is not the current tail_pipe, but what was previously the tail pipe - i.e. prior to the call to acquire_first_split_pipe The logic that follows will link free_pipe to the tail pipe, referring to the current tail pipe. However, since tail_pipe is cached from before the call to acquire_first_split_pipe, the wrong tail pipe will be used, and it will end up being linked to itself, creating a loop that, if traversed, will result in a soft hang. [How] Do not cache the tail pipe. Instead, check the tail pipe after the call to acquire_first_split_pipe is made. Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-