summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
AgeCommit message (Collapse)Author
2024-03-04drm/amd/display: add amdgpu_dm support for DCN351Hamza Mahfooz
Add Display Manager specific changes for DCN3.5.1. Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-30drm/amd/display: Add DCN35 DM SupportQingqing Zhuo
[Why & How] Add DM handling for DCN35. Signed-off-by: Qingqing Zhuo <Qingqing.Zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Change HDCP update sequence for DMBhawanpreet Lakha
Refactor the sequence in hdcp_update_display() to use mod_hdcp_update_display(). Previous sequence: - remove()->add() This Sequence was used to update the display, (mod_hdcp_update_display didn't exist at the time). This meant for any hdcp updates (type changes, enable/disable) we would remove, reconstruct, and add. This leads to unnecessary calls to psp eventually New Sequence using mod_hdcp_update_display(): - add() once when stream is enabled - use update() for all updates The update function checks for prev == new states and will not unnecessarily end up calling psp via add/remove. Reviewed-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-07-18drm/amd/display: Clean up style problems in amdgpu_dm_hdcp.cSrinivasan Shanmugam
Conform to Linux kernel coding style. And promote sysfs entry for set/get srm to kdoc. Suggested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-03-13drm/amd/display: Fix HDCP failing to enable after suspendBhawanpreet Lakha
[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 <Aurabindo.Pillai@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-28drm/amd/display: Updating Video Format Fall Back Policy.Jasdeep Dhillon
[WHY] Adding 1920x1080 as fail safe mode for Video Format Fall Back Policy. Reviewed-by: Jerry Zuo <Jerry.Zuo@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Jasdeep Dhillon <jdhillon@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-01-17drm/amd/display: hdcp not enabled on connector 0hersen wu
[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 <Daniel.Wheeler@amd.com> Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: hersen wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-01-17drm/amd/display: phase2 enable mst hdcp multiple displayshersen wu
[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 <Daniel.Wheeler@amd.com> Signed-off-by: hersen wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-10-27drm/amd/display: Fix HDCP 1.X 1A-04 failingBhawanpreet Lakha
[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 <mark.broadworth@amd.com> Reviewed-by: Aurabindo Pillai <Aurabindo.Pillai@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-07-25drm/amd/display: Reboot while unplug hdcp enabled dp from mst hubhersen wu
[Why] event_property_update does not check NULL pointer [How] check aconnector->base.state equals NULL Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: hersen wu <hersenxs.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-07-13drm/amd/display: Enable DCN314 in DMRoman Li
Add support for DCN 3.1.4 in Display Manager Signed-off-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-21drm/amd/display: Take emulated dc_sink into account for HDCPWayne Lin
[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 <daniel.wheeler@amd.com> Reviewed-by: Aurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-21drm/amd/display: Revert "drm/amd/display: Add flag to detect dpms force off ↵Wayne Lin
during HPD" 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 <daniel.wheeler@amd.com> Reviewed-by: Aurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-14drm/amd/display: update topology_update_input_v3 structQingqing Zhuo
[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 <Bhawanpreet.Lakha@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-25drm/display: Move HDCP helpers into display-helper moduleThomas Zimmermann
Move DRM's HDCP helper library into the display/ subdirectory and add it to DRM's display helpers. Split the header file into core and helpers. Update all affected drivers. No functional changes. v3: * fix Kconfig dependencies v2: * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-7-tzimmermann@suse.de
2022-02-18drm/amd/display: Add DCN315 DM SupportQingqing Zhuo
Add display manager support for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-17drm/amd/display: configure dc hw resource for DCN 3.1.6Prike Liang
- set DC version - add construct/destroy dc clock management function - register dcn interrupt handler Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-09-14drm/amd/display: Fix for null pointer access for ddc pin and aux engine.Meenakshikumar Somasundaram
[Why] Need a check for NULL pointer access for ddc pin and aux engine. [How] Adding a check for ddc pin and aux engine accesses. Reviewed-by: Jimmy Kizito <jimmy.kizito@amd.com> Acked-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-09-14drm/amd/display: Add flag to detect dpms force off during HPDAurabindo Pillai
[Why] When a connector is unplugged, dpms is forced off so that some connector allocations are cleared off. This is done outside the commit sequence from the userspace. This causes HUBP blank. Due to the blank hubp, a non blocking commit which queues flip will encounter a timeout waiting for the flip_done because prior to writing the surface flip address, hubp was in blank. [How] Add a marker to DM's crtc state and use this field to indicate whether dpms was forced off during an HPD. Check for this marker before queuing the flip. Reviewed-by: Anson Jacob <Anson.Jacob@amd.com> Acked-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-08-18drm/amd: consolidate TA shared memory structuresCandice Li
Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-28drm/amd/display: remove unused functionsWenjing Liu
[why] It has been decided that opm state query support will be dropped. Therefore link encryption enabled and save current encryption states won't be used anymore and there are no foreseeable usages in the future. We will remove these two interfaces for clean up. Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-22drm/amdgpu/display: fold DRM_AMD_DC_DCN3_1 into DRM_AMD_DC_DCNAlex Deucher
No need for a separate flag now that DCN3.1 is not in bring up. Fold into DRM_AMD_DC_DCN like previous DCN IPs. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amd/display: force CP to DESIRED when removing displayDingchen (David) Zhang
[WHY] - Commit from userspace could cause link stream to disable and hdcp auth to reset when the HDCP has already been enabled at the moment. CP should fall back to DESIRED from ENABLED in such cases. - This change was previously reverted due to a regression caused, which has now been cleared. [HOW] In hdcp display removal, change CP to DESIRED if at the moment CP is ENABLED before the auth reset and removal of linked list element. Signed-off-by: Dingchen (David) Zhang <dingchen.zhang@amd.com> Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Stylon Wang <stylon.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-04drm/amd/display: Add DCN3.1 HDCP supportNicholas Kazlauskas
New DTM interface is V3 and we need to extend our existing support to enable HDCP on DCN3.1. Version the helpers and fallback to the older versions on failure in the new interfaces. Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-13drm/amd/display: Initialize attribute for hdcp_srm sysfs fileDavid Ward
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
2021-04-20drm/amd/display: update hdcp display using correct CP type.Dingchen (David) Zhang
[why] currently we enforce to update hdcp display using TYPE0, but there is case that connector CP type prop be TYPE1 instead of type0. [how] using the drm prop of CP type of the connector as input argument. 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>
2021-04-09drm/amd/display: define mod_hdcp_display_disable_option structWenjing Liu
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-18drm/amdgpu/display: remove hdcp_srm sysfs on device removalNirmoy Das
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>
2021-02-02drm/amd/display: correct some hdcp variable namingWenjing Liu
[why] In HDCP update stream config interface, some variables are named as xxx_supported, but in fact the variable indicates whether or not xxx_enabled. Correct the naming so it is less confusing to read the code. Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-29drm/amd/display: fix return value check for hdcp_workFlora Cui
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>
2020-07-01drm/amdgpu/display: Unlock mutex on errorJohn van der Kamp
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>
2020-07-01drm/amd/display: enable assrBhawanpreet Lakha
[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>
2020-05-11drm/amd/amdgpu: Update update_config() logicLeo (Hanghong) Ma
[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>
2020-03-31drm/amd/display: increase HDCP authentication delayBhawanpreet Lakha
[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>
2020-03-31drm/amd/display: Correctly cancel future watchdog and callback eventsBhawanpreet Lakha
[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>
2020-03-31drm/amd/display: Don't try hdcp1.4 when content_type is set to type1Bhawanpreet Lakha
[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>
2020-03-09drm/amd/display: determine is mst hdcp based on stream instead of sink signalWenjing Liu
[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>
2020-02-06drm/amd/display: call psp set/get interfacesBhawanpreet Lakha
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>
2020-02-06drm/amd/display: Load srm before enabling HDCPBhawanpreet Lakha
[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>
2020-02-06drm/amd/display: Add sysfs interface for set/get srmBhawanpreet Lakha
[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>
2020-02-04drm/amd/display: Pass amdgpu_device instead of psp_contextBhawanpreet Lakha
[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>
2020-02-04drm/amd/display: Fix HW/SW state mismatchBhawanpreet Lakha
[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>
2019-11-26drm/amd/display: Null check aconnector in event_property_validateBhawanpreet Lakha
[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>
2019-11-19drm/amd/display: Refactor HDCP encryption status updateBhawanpreet Lakha
[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>
2019-11-19drm/amd/display: add force Type0/1 flagBhawanpreet Lakha
[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>
2019-11-19drm/amd/display: Refactor HDCP to handle multiple displays per linkBhawanpreet Lakha
[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>
2019-11-19drm/amd/display: Handle hdcp2.2 type0/1 in dmBhawanpreet Lakha
[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>
2019-11-19drm/amd/display: Enable HDCP 2.2Bhawanpreet Lakha
[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>
2019-10-04drm/amd/display: Make some functions staticzhengbin
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>
2019-10-03drm/amd/display: Update CP property based on HW queryBhawanpreet Lakha
[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>