linux-stable.git/drivers/gpu/drm/amd/display/modules/hdcp, branch linux-5.11.y Linux kernel stable tree drm/amd/display: add handling for hdcp2 rx id list validation 2021-05-19T08:29:34+00:00 Dingchen (David) Zhang dingchen.zhang@amd.com 2021-01-25T23:05:50+00:00 4de0a3f610a9303a4ddda0153dd7afd27188c10c [ Upstream commit 4ccf9446b2a3615615045346c97f8a1e2a16568a ] [why] the current implementation of hdcp2 rx id list validation does not have handler/checker for invalid message status, e.g. HMAC, the V parameter calculated from PSP not matching the V prime from Rx. [how] return a generic FAILURE for any message status not SUCCESS or REVOKED. Signed-off-by: Dingchen (David) Zhang <dingchen.zhang@amd.com> Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4ccf9446b2a3615615045346c97f8a1e2a16568a ]

[why]
the current implementation of hdcp2 rx id list validation does not
have handler/checker for invalid message status, e.g. HMAC, the V
parameter calculated from PSP not matching the V prime from Rx.

[how]
return a generic FAILURE for any message status not SUCCESS or
REVOKED.

Signed-off-by: Dingchen (David) Zhang <dingchen.zhang@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amd/display: Modify the hdcp device count check condition 2020-12-23T20:01:34+00:00 Martin Tsai martin.tsai@amd.com 2020-12-03T02:47:11+00:00 c2d61e309171437e042f4c859e88077fffee18e5 [why] Some MST display may not report the internal panel to DEVICE_COUNT, that makes the check condition always failed. [how] To update this condition with the reported device count + 1 (because the immediate repeater's internal panel is possibly not included in DEVICE_COUNT) Signed-off-by: Martin Tsai <martin.tsai@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[why]
Some MST display may not report the internal panel to DEVICE_COUNT,
that makes the check condition always failed.

[how]
To update this condition with the reported device count + 1
(because the immediate repeater's internal panel is possibly
not included in DEVICE_COUNT)

Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Acked-by: Bindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: set hdcp1 wa re-auth delay to 200ms 2020-11-02T20:32:03+00:00 Jake Wang haonan.wang2@amd.com 2020-10-22T19:23:16+00:00 12f86dfc075b51a27cac81005a4583b2631234ac [Why] Fail and restart timing for HDCP1 retry occurs too quickly. This would cause some MST monitors to show black screen. [How] Adjusted timing of fail and restart to 200ms. Signed-off-by: Jake Wang <haonan.wang2@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Fail and restart timing for HDCP1 retry occurs too quickly.
This would cause some MST monitors to show black screen.

[How]
Adjusted timing of fail and restart to 200ms.

Signed-off-by: Jake Wang <haonan.wang2@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: remove unneeded semicolon 2020-10-30T05:03:02+00:00 Tom Rix trix@redhat.com 2020-10-27T20:07:08+00:00 0b924cd60d43f411f3133fbb39c1e4c82c7b2b18 A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
A semicolon is not needed after a switch statement.

Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Don't log hdcp module warnings in dmesg 2020-09-17T21:56:47+00:00 Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com 2020-09-15T21:26:29+00:00 143678d12b6d5eb883366b335b22236e6a8e34de [Why] DTM topology updates happens by default now. This results in DTM warnings when hdcp is not even being enabled. This spams the dmesg and doesn't effect normal display functionality so it is better to log it using DRM_DEBUG_KMS() [How] Change the DRM_WARN() to DRM_DEBUG_KMS() Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
DTM topology updates happens by default now. This results in DTM
warnings when hdcp is not even being enabled. This spams the dmesg
and doesn't effect normal display functionality so it is better to log it
using DRM_DEBUG_KMS()

[How]
Change the DRM_WARN() to DRM_DEBUG_KMS()

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Don't use DRM_ERROR() for DTM add topology 2020-09-15T21:52:41+00:00 Bhawanpreet Lakha Bhawanpreet.Lakha@amd.com 2020-08-28T15:09:38+00:00 bd80d584cd8e2502b6be48544a14970016c86aa4 [Why] Previously we were only calling add_topology when hdcp was being enabled. Now we call add_topology by default so the ERROR messages are printed if the firmware is not loaded. This error message is not relevant for normal display functionality so no need to print a ERROR message. [How] Change DRM_ERROR to DRM_INFO Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Previously we were only calling add_topology when hdcp was being enabled.
Now we call add_topology by default so the ERROR messages are printed if
the firmware is not loaded.

This error message is not relevant for normal display functionality so
no need to print a ERROR message.

[How]
Change DRM_ERROR to DRM_INFO

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fix CP_IRQ clear bit and logic 2020-09-15T21:52:40+00:00 Harmanprit Tatla harmanprit.tatla@amd.com 2020-08-20T19:52:18+00:00 5cd04c4846a3f910fc8a7150cae81542a0ab32d3 [Why] Currently clearing the wrong bit for CP_IRQ, and logic on when to clear needs to be fixed. [How] Corrected bit to clear and improved logic for decision to clear. Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Currently clearing the wrong bit for CP_IRQ, and logic on when to
clear needs to be fixed.

[How]
Corrected bit to clear and improved logic for decision to clear.

Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Add CP_IRQ clear capability 2020-09-15T21:52:40+00:00 Harmanprit Tatla harmanprit.tatla@amd.com 2020-08-19T21:39:45+00:00 958000cb24cc2db5f3ce1c70b9ad2b3e20b73581 [Why] Currently we do not clear the CP_IRQ bit upon receiving it. [How] Added a function to clear CP_IRQ bit. Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Currently we do not clear the CP_IRQ bit upon receiving it.

[How]
Added a function to clear CP_IRQ bit.

Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: fix typo 2020-04-09T14:43:16+00:00 Joseph Gravenor joseph.gravenor@amd.com 2020-04-05T20:40:50+00:00 49c4a8b6d93b533e266cb9f76eae4067592e077e [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> 
[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>
drm/amd/display: Remove hdcp display state with mst fix 2020-04-09T14:43:16+00:00 Isabel Zhang isabel.zhang@amd.com 2020-04-05T20:40:44+00:00 2deade5ede56581722c0d7672f28b09548dc0fc4 [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> 
[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>