linux/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c, branch v6.4

drm/amd/display: Fix HDCP failing to enable after suspend

2023-03-13T21:27:48Z

[Why] On resume some displays are not ready for HDCP, so they will fail if we start the hdcp authentintication too soon. Add a delay so that the displays can be ready before we start. NOTE: Previoulsy this delay was set to 3 seconds but it was causing issues with compliance, 2 seconds should enough for compliance and the s3 resume case. [How] Change the Delay to 2 seconds. Reviewed-by: Aurabindo Pillai Acked-by: Qingqing Zhuo Signed-off-by: Bhawanpreet Lakha Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Updating Video Format Fall Back Policy.

2023-02-28T19:29:35Z

[WHY] Adding 1920x1080 as fail safe mode for Video Format Fall Back Policy. Reviewed-by: Jerry Zuo Acked-by: Qingqing Zhuo Signed-off-by: Jasdeep Dhillon Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: hdcp not enabled on connector 0

2023-01-17T20:41:30Z

[Why] incorrect skip when drm_connector.index = 0 within event_property_validate and update [How] handle hdcp validate and update for connector 0 Tested-by: Daniel Wheeler Reviewed-by: Bhawanpreet Lakha Acked-by: Rodrigo Siqueira Signed-off-by: hersen wu Signed-off-by: Alex Deucher

drm/amd/display: phase2 enable mst hdcp multiple displays

2023-01-17T20:41:19Z

[why] For MST topology with 1 physical link and multiple connectors (>=2), e.g. daisy cahined MST + SST, or 1-to-multi MST hub, if userspace set to enable the HDCP simultaneously on all connected outputs, the commit tail iteratively call the hdcp_update_display() for each display (connector). However, the hdcp workqueue data structure for each link has only one DM connector and encryption status members, which means the work queue of property_validate/update() would only be triggered for the last connector within this physical link, and therefore the HDCP property value of other connectors would stay on DESIRED instead of switching to ENABLED, which is NOT as expected. [how] Use array of AMDGPU_DM_MAX_DISPLAY_INDEX for both aconnector and encryption status in hdcp workqueue data structure for each physical link. For property validate/update work queue, we iterates over the array and do similar operation/check for each connected display. Tested-by: Daniel Wheeler Signed-off-by: hersen wu Signed-off-by: Alex Deucher

drm/amd/display: Fix HDCP 1.X 1A-04 failing

2022-10-27T18:43:39Z

[Why] On some linux based OS, the hotplug->HDCP start takes longer than 4seconds (by ~100ms) This is due to the HDCP delay (3 sec) so we only have 1 second to hotplug->stream enablement, which is not enough for certain OS configs. [How] Change the Delay to 0 seconds. From testing it seems like 0 Seconds can pass 1.x and 2.x compliances Tested-by: Mark Broadworth Reviewed-by: Aurabindo Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Reboot while unplug hdcp enabled dp from mst hub

2022-07-25T21:15:50Z

[Why] event_property_update does not check NULL pointer [How] check aconnector->base.state equals NULL Reviewed-by: Bhawanpreet Lakha Acked-by: Alex Hung Signed-off-by: hersen wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Enable DCN314 in DM

2022-07-14T00:57:05Z

Add support for DCN 3.1.4 in Display Manager Signed-off-by: Roman Li Signed-off-by: Alex Deucher

drm/amd/display: Take emulated dc_sink into account for HDCP

2022-06-21T22:17:23Z

[Why] While updating the config of hdcp, we use the sink_singal type of the dc_sink to decide the HDCP operation mode. However, it doesn't consider the case when the sink is a emulated one. [How] Take dc_em_sink into account while updating HDCP config. Tested-by: Daniel Wheeler Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Wayne Lin Signed-off-by: Alex Deucher

drm/amd/display: Revert "drm/amd/display: Add flag to detect dpms force off during HPD"

2022-06-21T22:17:22Z

This reverts commit 035f54969bb2c1a5ced52f43e4ef393e0c0f6bfa. The reverted commit was trying to fix side effect brought by commit 3c4d55c9b9be ("drm/amd/display: turn DPMS off on connector unplug") However, * This reverted commit will have mst case never call dm_set_dpms_off() which conflicts the idea of original commit 3c4d55c9b9be ("drm/amd/display: turn DPMS off on connector unplug") That's due to dm_crtc_state is always null since the input parameter aconnector is the root device (source) of mst topology. It's not an end stream sink within the mst topology. * Setting dpms off should be triggered by usermode. Besdies, it seems usermode does release relevant resource for mst & non-mst case when unplug connecotr now. Which means we no longer need both commits now: commit 3c4d55c9b9be ("drm/amd/display: turn DPMS off on connector unplug") commit 035f54969bb2 ("drm/amd/display: Add flag to detect dpms force off during HPD") Tested-by: Daniel Wheeler Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Acked-by: Lyude Paul Signed-off-by: Wayne Lin Signed-off-by: Alex Deucher

drm/amd/display: update topology_update_input_v3 struct

2022-06-15T01:38:40Z

[Why] DIO parameters were missing in topology_update_intput_v3 struct. [How] Add DIO parameters in v3 struct and update in functions perspectively. Reviewed-by: Bhawanpreet Lakha Acked-by: Hamza Mahfooz Signed-off-by: Qingqing Zhuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher