drm/amd/display: Refactor HDCP to handle multiple displays per link

[Why]
We need to do this to support HDCP over MST

Currently we save a display per link, in a MST case we need to save
multiple di

drm/amd/display: Refactor HDCP to handle multiple displays per link

[Why]
We need to do this to support HDCP over MST

Currently we save a display per link, in a MST case we need to save
multiple displays per link.

[How]
We can create an array per link to cache the displays, but it
complicates the design. Instead we can use the module to cache the
displays.

Now we will always add all the displays to the module, but we use the
adjustment flag to disable hdcp on all of them before they are added.

When we want to enable hdcp we just query the display(cache), remove
it then add it back with different adjustments. Its the similar for
disable.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Handle hdcp2.2 type0/1 in dm

[Why]
HDCP 2.2 uses type0 and type1 content type. This is passed to the receiver
to stream the proper content.

For example, in a MST case if the main
d

drm/amd/display: Handle hdcp2.2 type0/1 in dm

[Why]
HDCP 2.2 uses type0 and type1 content type. This is passed to the receiver
to stream the proper content.

For example, in a MST case if the main
device is HDCP2.2 capable but the secondary device is only 1.4 capabale
we can use Type0

Type0 content: use HDCP 1.4 or HDCP2.2 type0
Type1 content: Only use HDCP 2.2 type1

[How]
We use the "hdcp content type" property in drm. We use the
disable_type1 flag in hdcp module to select the type based on the
properties.

For updating the property we use the same logic as 1.4, but now we
consider content_type as well and update the property if the
requirements are met

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Enable HDCP 2.2

[Why]
HDCP 2.2 was disabled, we need to enable it

[How]
-Update display topology to support 2.2
-Unset hdcp2.disable in update_config
-Change logic of event_update_

drm/amd/display: Enable HDCP 2.2

[Why]
HDCP 2.2 was disabled, we need to enable it

[How]
-Update display topology to support 2.2
-Unset hdcp2.disable in update_config
-Change logic of event_update_property, now we set the property to be
ENABLED for any level of encryption (2.2 or 1.4).

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Make some functions static

Fix sparse warnings:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:32:6: warning: symbol 'lp_write_i2c' was not declared. Should it be

drm/amd/display: Make some functions static

Fix sparse warnings:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:32:6: warning: symbol 'lp_write_i2c' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:42:6: warning: symbol 'lp_read_i2c' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:52:6: warning: symbol 'lp_write_dpcd' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:59:6: warning: symbol 'lp_read_dpcd' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Update CP property based on HW query

[Why]
We need to use HW state to set content protection to ENABLED.
This way we know that the link is encrypted from the HW side

[How]
Create a

drm/amd/display: Update CP property based on HW query

[Why]
We need to use HW state to set content protection to ENABLED.
This way we know that the link is encrypted from the HW side

[How]
Create a workqueue that queries the HW every ~2seconds, and sets it to
ENABLED or DESIRED based on the result from the hardware

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Create dpcd and i2c packing functions

[Why]
We need to read and write specific i2c and dpcd messages.

[How]
Created static functions for packing the dpcd and i2c messages for hdcp.

drm/amd/display: Create dpcd and i2c packing functions

[Why]
We need to read and write specific i2c and dpcd messages.

[How]
Created static functions for packing the dpcd and i2c messages for hdcp.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Create amdgpu_dm_hdcp

[Why]
We need to interact with the hdcp module from the DM, the module
has to be interacted with in terms of events

[How]
Create the files needed for linux hd

drm/amd/display: Create amdgpu_dm_hdcp

[Why]
We need to interact with the hdcp module from the DM, the module
has to be interacted with in terms of events

[How]
Create the files needed for linux hdcp. These files manage the events
needed for the dm to interact with the hdcp module.

We use the kernel work queue to process the events needed for
the module

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Initialize attribute for hdcp_srm sysfs file

commit fe1c97d008f86f672f0e9265f180c22451ca3b9f upstream.

It is stored in dynamically allocated memory, so sysfs_bin_at

drm/amd/display: Initialize attribute for hdcp_srm sysfs file

commit fe1c97d008f86f672f0e9265f180c22451ca3b9f upstream.

It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must
be called to initialize it. (Note: "initialization" only sets the .attr.key
member in this struct; it does not change the value of any other members.)

Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during boot:

BUG: key ffff9248900cd148 has not been registered!

Fixes: 9037246bb2da ("drm/amd/display: Add sysfs interface for set/get srm")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1586
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: David Ward <david.ward@gatech.edu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

drm/amdgpu/display: remove hdcp_srm sysfs on device removal

[ Upstream commit e96b1b2974989c6a25507b527843ede7594efc85 ]

Fixes: 9037246bb2da5 ("drm/amd/display: Add sysfs interface

drm/amdgpu/display: remove hdcp_srm sysfs on device removal

[ Upstream commit e96b1b2974989c6a25507b527843ede7594efc85 ]

Fixes: 9037246bb2da5 ("drm/amd/display: Add sysfs interface for set/get srm")

Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/amd/display: fix return value check for hdcp_work

max_caps might be 0, thus hdcp_work might be ZERO_SIZE_PTR

Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Feifei

drm/amd/display: fix return value check for hdcp_work

max_caps might be 0, thus hdcp_work might be ZERO_SIZE_PTR

Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amdgpu/display: Unlock mutex on error

Make sure we pass through ret label to unlock the mutex.

Signed-off-by: John van der Kamp <sjonny@suffe.me.uk>
Signed-off-by: Alex Deuc

drm/amdgpu/display: Unlock mutex on error

Make sure we pass through ret label to unlock the mutex.

Signed-off-by: John van der Kamp <sjonny@suffe.me.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: enable assr

[Why]
assr is content protection for eDP, in order to use it we need to call
psp ta (dtm)

[How]
We have a enable_assr callback, hook into th

drm/amd/display: enable assr

[Why]
assr is content protection for eDP, in order to use it we need to call
psp ta (dtm)

[How]
We have a enable_assr callback, hook into this and call the correct psp
cmd id to enable assr.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@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>

show more ...

drm/amd/amdgpu: Update update_config() logic

[Why]
For MST case: when update_config is called to disable a stream,
this clears the settings for all the streams on that link.
We s

drm/amd/amdgpu: Update update_config() logic

[Why]
For MST case: when update_config is called to disable a stream,
this clears the settings for all the streams on that link.
We should only clear the settings for the stream that was disabled.

[How]
Clear the settings after the call to remove display is called.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: increase HDCP authentication delay

[Why]
Some displays have an issue where the hdcp chips are initialized after the
display has already lit up. This means we can som

drm/amd/display: increase HDCP authentication delay

[Why]
Some displays have an issue where the hdcp chips are initialized after the
display has already lit up. This means we can sometimes authentication too early
and cause authentication failures.

This happens when HDCP is enabled and the display is power cycled. Normally we
will authenticate 2 seconds after the display is lit, but some displays need a
bit more time.

[How]
Increase delay to 3 second before we start authentication.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Correctly cancel future watchdog and callback events

[Why]
-We need to cancel future callbacks/watchdogs events when a callback/watchdog event happens

[How]

drm/amd/display: Correctly cancel future watchdog and callback events

[Why]
-We need to cancel future callbacks/watchdogs events when a callback/watchdog event happens

[How]
-fix typo in event_callback()
-cancel callback, not watchdog
-cancel watchdog events in event_watchdog_timer().

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Don't try hdcp1.4 when content_type is set to type1

[Why]
When content type property is set to 1. We should enable hdcp2.2 and if we cant
then stop. Currently the wa

drm/amd/display: Don't try hdcp1.4 when content_type is set to type1

[Why]
When content type property is set to 1. We should enable hdcp2.2 and if we cant
then stop. Currently the way it works in DC is that if we fail hdcp2, we will
try hdcp1 after.

[How]
Use link config to force disable hdcp1.4 when type1 is set.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

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

[why]
It is possible even if sink signal is MST but driver enables SST stream.
We should not determine i

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

[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 <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: call psp set/get interfaces

Call the cmd ids for set/get srm according to the sysfs call

v2: Use define for the magic number

Signed-off-by: Bhawanpreet Lak

drm/amd/display: call psp set/get interfaces

Call the cmd ids for set/get srm according to the sysfs call

v2: Use define for the magic number

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Load srm before enabling HDCP

[Why]
we need to load SRM before we start HDCP. Because for S3 case the sysfs call will be
after we have already enabled HDCP, so we mi

drm/amd/display: Load srm before enabling HDCP

[Why]
we need to load SRM before we start HDCP. Because for S3 case the sysfs call will be
after we have already enabled HDCP, so we might not be using the latest SRM

[How]
Set srm before starting HDCP.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Add sysfs interface for set/get srm

[Why]
PSP doesn't have the ability to store SRM in a non-volatile memory. And since
the kernel cannot write to the storage direc

drm/amd/display: Add sysfs interface for set/get srm

[Why]
PSP doesn't have the ability to store SRM in a non-volatile memory. And since
the kernel cannot write to the storage directly, we need usermode to facilitate
this

As per spec the SRM needs to be persistent so this interface is to be
called by the usermode anytime the system goes down/powers on

*boot/resume: load from storage
*shutdown/suspend: save to storage

[How]
Provide a sysfs interface so that the usermode can set/get srm at the right times

save to storage: call "cat /sys/class/drm/card0/device/hdcp_srm > file" after boot and resume
-driver calls psp_get_srm() to get the stored srm and outputs it

load from storage: call "cat file > /sys/class/drm/card0/device/hdcp_srm" before shutdown and suspend
-driver reads the file from sysfs and calls psp_set_srm() to send the SRM to PSP

v2:
-update commit description
-add comment about sysfs file handling in the code

v3:
- squash in use after free fix (Dan Carpenter)

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Pass amdgpu_device instead of psp_context

[Why]
We need this to create sysfs (followup patch)

[How]
Change the parameter

Signed-off-by: Bhawanpreet

drm/amd/display: Pass amdgpu_device instead of psp_context

[Why]
We need this to create sysfs (followup patch)

[How]
Change the parameter

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Fix HW/SW state mismatch

[Why]
When we disable a connector we don't explicitly remove it from the module so the
display is still cached(SW) in the hdcp_module.

drm/amd/display: Fix HW/SW state mismatch

[Why]
When we disable a connector we don't explicitly remove it from the module so the
display is still cached(SW) in the hdcp_module.

SST: no issues because we can only have 1 display per link

MST: We have x displays per link, now if we disable 1 we don't remove it from the
module so the module has x display cached(SW).

If we try to enable HDCP, psp verification will fail because we are reporting x
displays while the HW only has x-1 display enabled

[How]
Check the callback for when we disable stream and call remove display.

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>

show more ...

drm/amd/display: Null check aconnector in event_property_validate

[Why]
previously event_property_validate was only called after we enabled the display.
But after "Refactor HDCP to h

drm/amd/display: Null check aconnector in event_property_validate

[Why]
previously event_property_validate was only called after we enabled the display.
But after "Refactor HDCP to handle multiple displays per link" this function
can be called at any time. In certain cases we don't have a aconnector

[How]
Null check aconnector and exit early. This is ok because we only need to check the
ENABLED->DESIRED transition if a connector exists.

Fixes: b1abe5586ffc ("drm/amd/display: Refactor HDCP to handle multiple displays per link")
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: Refactor HDCP encryption status update

[Why]
The old way was to poll PSP and update the properties. But due to a
limitation in the PSP interface this doesn't work fo

drm/amd/display: Refactor HDCP encryption status update

[Why]
The old way was to poll PSP and update the properties. But due to a
limitation in the PSP interface this doesn't work for MST.

[How]
According to PSP if set_encryption return success, the link is encrypted
and the only way it will not be is if we get a link loss(which we handle
already).

So this method should be good enough to report HDCP status.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...

drm/amd/display: add force Type0/1 flag

[Why]
Before we had a disable_type1 flag, this forced HDCP 2.2 to type0
There was no way to force type1.

[How]
Remove disable_typ

drm/amd/display: add force Type0/1 flag

[Why]
Before we had a disable_type1 flag, this forced HDCP 2.2 to type0
There was no way to force type1.

[How]
Remove disable_type1 flag and instead add a flag to force type0/1.

Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

show more ...