Testing HDCP 1.4 becomes tough since the only way our code comes to
HDCP 1.4 pathway is if the monitor only supports HDCP 1.4 which
becomes tough to find sometimes.
Setting this debug_fs entry will force use to use the HDCP 1.4 path
so that more robust HDCP 1.4 testing can take place.
--v2
-Move the code to intel_hdcp.c [Jani]
-Remove useless debug logging [Jani]
-Remove Force_HDCP from the debug file [Jani]
--v3
-Remove leftover debug loggings [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250213082541.3772212-1-suraj.kandpal@intel.com
When topology changes, before beginning a new HDCP authentication by
sending AKE_init message we need to first authenticate only the
repeater. Only after repeater authentication failure, it makes sense
to start a new HDCP authentication. Even though it made sense to not
enable HDCP directly from check_link and schedule it for later, repeater
authentication needs to be done immediately.
--v2
-Fix comment grammatical errors [Ankit]
Fixes: 47ef55a8b7 ("drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217083723.2883317-1-suraj.kandpal@intel.com
Make sure that the first read/write in hdcp2_authentication_key_exchange
are only retried when we have either DP/DPMST encoder connected,
since we do this to give docks and dp encoders some extra time to
get their HDCP DPCD registers ready only for DP/DPMST encoders as
this issue is only observed here no need to burden other encoders
with extra retries as this causes the HDMI connector to have some
other timing issue and fails HDCP authentication.
--v2
-Add intent of patch [Chaitanya]
-Add reasoning for loop [Jani]
-Make sure we forfiet the 50ms wait for non DP/DPMST encoders.
--v3
-Remove the is_dp_encoder check [Jani/Chaitanya]
-Make the commit message more clearer [Jani]
Fixes: 9d5a05f86d ("drm/i915/hdcp: Retry first read and writes to downstream")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241104035951.517837-1-suraj.kandpal@intel.com
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
hdcp 2.2 and we are not using an hdmi transcoder and it need to be
enabled when we are using an HDMI transcoder to enable HDCP 1.4.
We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so
we cannot depend on the value being 0 by default everytime which calls
for seprate handling of HDCP 1.4 case.
--v2
-Use the exising function and modify it based on a bool rather than
have a different function [Matt]
--v3
-No need for kzalloc [Jani]
--v4
-i915_reg_t should not be pointer [Jani]
-use rekey_bit to ensure when writing to reg everything is initialized
Bspec: 69964, 50493, 50054
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241107022807.869744-1-suraj.kandpal@intel.com
The TRANS_DDI_FUNC_CTL bit used to enable/disable HDCP rekeying
has moved from bit 12 (Xe2) to bit 15 (Xe3); update the RMW
toggle accordingly.
Also drop the misleading workaround comment tag on this function
since disabling of HDCP rekeying is something that happens on
all platforms, not just those impacted by that workaround.
While we're here, also re-order the if/else ladder to use
standard "newest platform first" order.
v2: add additional definition instead of function, commit message typo
fix and update.
v3: restore lost conditional from v2.
v4: subject line and subject message updated, fix the if ladder order,
fix the bit definition order.
v5: Add the bspec link and remove the Wa comment tag
v6: Rebase over new changes
v7: Fix commit subject and message, reladder the if/else blocks
Bspec: 69964
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241104185055.739605-1-suraj.kandpal@intel.com
Use x100, or ver * 100 + rel, versions for full IP version checks,
similar to what xe driver does:
- Replace IP_VER(14, 1) inline with 1401, etc.
- Convert DISPLAY_VER_FULL() to DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP()
This makes ver.rel versions easier to use, follows the xe driver
pattern, and drops the dependency on the IP_VER() macro.
v2: Rebase, drop IP_VER() from xe compat headers
v3: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com
Retry the first read and write to downstream at least 10 times
with a 50ms delay if not hdcp2 capable(dock decides to stop advertising
hdcp2 capability for some reason). The reason being that
during suspend resume Dock usually keep the HDCP2 registers inaccesible
causing AUX error. This wouldn't be a big problem if the userspace
just kept retrying with some delay while it continues to play low
values content but most userpace applications end up throwing an error
when it receives one from KMD. This makes sure we give the dock
and the sink devices to complete its power cycle and then try HDCP
authentication.
--v2
-Add more details in comment [Jani]
-fix looping condition [Jani]
-optimize loop exit condition [Jani]
--v3
-Add comment explaining why the loop was added [Ankit]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240927060437.1422942-2-suraj.kandpal@intel.com
Disable HDCP Line Rekeying when HDCP ver > 1.4 and when we are
on HDMI TMDS operation for DISPLAY_VER >= 14.
--v2
-Wa to be mentioned in comments not in commit message [Jani]
-Remove blankline [Jani]
--v3
-No need to write what is being done in comments when code
is self explanatory [Jani]
--v4
-Add comment regarding need of this WA when in TMDS mode
[Chaitanya]
-Write in chicken register for MTL [CHaitanya]
--v5
-Fix comment [Chaitanya]
-Use correct set and clear value in intel_de_rmw [Chaitanya]
--v6
-No need to define C, D chicken bits it gets calculated [Animesh]
Bspec: 49273
Bspec: 69964
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507062243.1076047-2-suraj.kandpal@intel.com
Create a remote HDCP capability shim function which can read the
remote monitor HDCP capability when in MST configuration.
--v2
-Add an assertion to make sure only mst encoder call this remote_cap
function [Ankit]
--v3
-rename remote_hdcp_cap to remote_hdcp_capability [Jani]
--v4
-fix hdcp2_prerequisite check condition
-Move intel_dp_hdcp_get_remote_capability to dp_mst shim instead of
having it in dp shim [Ankit]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226051017.1652970-2-suraj.kandpal@intel.com
Update intel_hdcp_shim funcs specifically read_2_2_message,
write_2_2_message and config_stream_type to use intel_connector
argument instead of intel_digital_port as this will help in getting
correct aux later for dp mst scenarios also already hdcp funcs
derive digital_port from connector and then many funcs again get back
the connector from dig_port which doesn't seem right.
Connector specific hdcp functions can derive dig_port on need basis.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828063401.600414-2-suraj.kandpal@intel.com
