kernel/linux.git/drivers/gpu/drm/amd/display/modules/inc, branch linux-5.9.y

drm/amd/display: Fix incorrect rounding for 10Hz refresh range

2020-07-02T16:02:54+00:00

[Why] In cases where refresh range is slightly below 10, FreeSync is not active or supported. Need to round values before checking refresh range in order to have FreeSync supported in these cases. [How] Remove redundant values and round values before checking valid refresh range. Signed-off-by: Jaehyun Chung Reviewed-by: Aric Cyr Acked-by: Anthony Koo Acked-by: Eryk Brol Signed-off-by: Alex Deucher

drm/amd/display: Handle persistence in DM

2020-05-28T18:00:47+00:00

[Why] Remove dm_write_persistent_data and dm_read_persistent_data as persistence should be handled in DM. [How] Remove functions. Move read/write calls into DM layer while maintaining logic. Signed-off-by: Jaehyun Chung Reviewed-by: Anthony Koo Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Change infopacket type programming

2020-04-22T22:11:47+00:00

[Why] Certain displays may experience blanking if infopacket max range does not equal nominal refresh rate. [How] Add additional infopacket versions to program range to full or forced range in freesync states. This does not change the vrr logic. Signed-off-by: Haiyi Zhou Reviewed-by: Anthony Koo Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: fix typo

2020-04-09T14:43:16+00:00

[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 Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Remove hdcp display state with mst fix

2020-04-09T14:43:16+00:00

[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 Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Revert change to HDCP display states

2020-03-31T16:26:14+00:00

[Why] Change is causing a regression where the OPC app no longer functions properly. [How] Revert the changelist causing the issue. Signed-off-by: Isabel Zhang Reviewed-by: Yongqiang Sun Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: differentiate vsc sdp colorimetry use criteria between MST and SST

2020-03-19T04:03:04+00:00

[Why] We should check MST BU support capability on output port before building vsc info packet. [How] Add a new definition for port and sink capability check. Signed-off-by: Martin Tsai Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Remove redundant hdcp display state

2020-03-19T04:03:04+00:00

[Why] Due to previous code changes displays which are in active state immediately transition to the active and added state. This makes the two states redundant and unnecessary. [How] Instead of updating the device state to active and added after successful addition, change state to inactive if addition failed. Also, change references to active and added state to just added state. Signed-off-by: Isabel Zhang Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: determine is mst hdcp based on stream instead of sink signal

2020-03-09T17:49:06+00:00

[why] It is possible even if sink signal is MST but driver enables SST stream. We should not determine if we should do MST authentication based on sink's capability. Instead we should determine whether to do MST authentication based on what we have enabled in stream. Signed-off-by: Wenjing Liu Reviewed-by: Ashley Thomas Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Workaround to do HDCP authentication twice on certain displays

2020-03-05T05:30:04+00:00

[Why] When transitioning from SST to MST, the HDCP repeater in some MST displays will enter a bad state. The HDCP repeater is recovered after failing and performing authentication again. [How] Add monitor patch to trigger HDCP authentication failure after encryption is enabled and re-authenticate. Signed-off-by: George Shen Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher