summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display/intel_hdcp.c
AgeCommit message (Collapse)AuthorFilesLines
2022-06-24Merge tag 'drm-intel-next-2022-06-22' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-intel into drm-next - General driver clean-up (Jani, Ville, Julia) - DG2 enabling (Anusha, Vandita) - Fix sparse warnings (Imre, Jani) - DMC MMIO range checks (Anusha) - Audio related fixes (Jani) - Runtime PM fixes (Anshuman) - PSR fixes (Jouni, Jose) - Media freq factor and per-gt enhancements (Ashutosh, Dale) - DSI fixes for ICL+ (Jani) - Disable DMC flip queue handlers (Imre) - ADL_P voltage swing updates (Balasubramani) - Use more the VBT for panel information (Ville, Animesh) - Fix on Type-C ports with TBT mode (Vivek) - Improve fastset and allow seamless M/N changes (Ville) - Accept more fixed modes with VRR/DMRRS panels (Ville) - FBC fix (Jose) - Remove noise logs (Luca) - Disable connector polling for a headless SKU (Jouni) - Sanitize display underrun reporting (Ville) - ADL-S display PLL w/a (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YrNzP2WTf3WBvpvd@intel.com
2022-05-20drm/i915/pcode: Extend pcode functions for multiple gt'sAshutosh Dixit1-1/+1
Each gt contains an independent instance of pcode. Extend pcode functions to interface with pcode on different gt's. To avoid creating dependency of display functionality on intel_gt, pcode function interfaces are exposed in terms of uncore rather than intel_gt. Callers have been converted to pass in the appropritate (i915 or intel_gt) uncore to the pcode functions. v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo) v3: Retain previous function names to eliminate needless #defines (Rodrigo) v4: Move out i915_pcode_init() to a separate patch (Tvrtko) Remove duplicated drm_err/drm_dbg from intel_pcode_init() (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519085732.1276255-2-tvrtko.ursulin@linux.intel.com [tursulin: fixup merge conflict]
2022-04-25drm/display: Move HDCP helpers into display-helper moduleThomas Zimmermann1-1/+1
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-28drm/i915: Move intel_display_power_well_is_enabled() to ↵Imre Deak1-0/+1
intel_display_power_well.c Move intel_display_power_well_is_enabled() to intel_power_well.c, as a step towards making the low-level power well internals (i915_power_well_ops/desc structs) hidden. Eventually the call to this function and in general accessing power wells directly from elsewhere in the driver should be replaced by the use of power domains. No functional change. Suggested-by: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222165137.1004194-9-imre.deak@intel.com
2022-01-13drm/i915/pcode: rename sandybridge_pcode_* to snb_pcode_*Jani Nikula1-2/+1
Prefer acronym-based naming to be in line with the rest of the driver. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220112111740.1208374-1-jani.nikula@intel.com
2021-10-14drm/i915: split out intel_pcode.[ch] to separate fileJani Nikula1-3/+3
The snb+ pcode mailbox code is not sideband, so split it out to a separate file. As can be seen from the #include changes, very few places use both sideband and pcode. Code movement only. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/185deb18eb739e5ae019e27834b9997dcc1347bc.1634207064.git.jani.nikula@intel.com
2021-09-09drm/i915/hdcp: reuse rx_info for mst stream type1 capability checkJuston Li1-28/+36
On some MST docking stations, rx_info can only be read after RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set otherwise the read will return -EIO. This behavior causes the mst stream type1 capability test to fail to read rx_info and determine if the topology supports type1 and fallback to type0. To fix this, check for type1 capability when we receive rx_info within the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead of an explicit read just for type1 capability checking. This does require moving where we set stream_types to after hdcp2_authenticate_sink() when we get rx_info but this occurs before we do hdcp2_propagate_stream_management_info. Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for that as well. Changes since v5: - rename intel_set_stream_types() to intel_hdcp_prepare_streams() (Anshuman) Changes since v4: - move topology_type1_capable to intel_digital_port and rename it as hdcp_mst_type1_capable (Anshuman) - make a helper function intel_set_stream_types() to set stream types in hdcp2_authenticate_and_encrypt() (Anshuman) - break on failure to set stream types and retry instead of returning - remove no longer used declaration for streams_type1_capable() Changes since v2: - Remove no longer used variables in _intel_hdcp2_enable() Signed-off-by: Juston Li <juston.li@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Tested-by: Suraj K <suraj.kandpal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-4-juston.li@intel.com
2021-05-05drm/i915: Don't include intel_de.h from intel_display_types.hVille Syrjälä1-0/+1
Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com
2021-04-14drm/i915/display: rename display version macrosLucas De Marchi1-1/+1
While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
2021-04-14drm/i915/display: Eliminate IS_GEN9_{BC,LP}Matt Roper1-4/+5
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-03-23drm/i915/display: Simplify GLK display version testsMatt Roper1-1/+0
GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info structure, the rest of this patch is generated with a Coccinelle semantic patch. Note that we also need to switch any code that matches gen10 today but *not* GLK to be CNL-specific: @@ expression dev_priv; @@ - DISPLAY_VER(dev_priv) > 9 + DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ ( - DISPLAY_VER(dev_priv) >= 10 && E + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E | - DISPLAY_VER(dev_priv) >= 10 + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) | - IS_DISPLAY_RANGE(dev_priv, 10, E) + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) ) @@ expression dev_priv, E, E2; @@ ( - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) + E || E2 || IS_DISPLAY_VER(dev_priv, 10) | - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_VER(dev_priv, 10) ) @@ expression dev_priv; @@ - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 9) @@ expression dev_priv; @@ ( - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) < 10 | - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) + E || DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_RANGE(dev_priv, 10, E) @@ expression dev_priv; @@ ( - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv) + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) | - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - !(DISPLAY_VER(dev_priv) >= E) + DISPLAY_VER(dev_priv) < E v2: - Convert gen10 conditions that don't include GLK into CNL conditions. (Ville) v3: - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville) v3.1: - Manually re-add the ".display.version = 10" to glk_info after regenerating patch via Coccinelle. v4: - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Cc: Ville Syrjälä <ville.syrjala@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com
2021-03-23drm/i915/display: Eliminate most usage of INTEL_GEN()Matt Roper1-5/+5
Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
2021-03-22drm/i915/hdcp: return correct error codeAnshuman Gupta1-1/+2
hdcp2_enable_stream_encryption shouldn't get called in case of any port authentication or encryption error, though hdcp2_enable_stream_encryption checks for link encryption before enabling stream encryption and returns error but this return error code won't be correct in case of any error due to port authentication and encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-4-anshuman.gupta@intel.com
2021-03-22drm/i915/hdcp: link hdcp2 recovery on link enc stoppedAnshuman Gupta1-1/+12
When stream encryption enabling fails due to Link encryption status has stopped, prepare HDCP2 for recovery by disabling port authentication and encryption such that it can re-attempt port authentication and encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-3-anshuman.gupta@intel.com
2021-03-22drm/i915/hdcp: HDCP2.2 MST Link failure recoveryAnshuman Gupta1-4/+6
DP MST Link Check performed only for the connector involved with HDCP port authentication and encryption, for other connector it simply returns link check with true and update the uevent. Therefore in case of HDCP 2.2 link failure, disable HDCP encryption and de-authenticate the port so next time it can enable port authentication and encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-2-anshuman.gupta@intel.com
2021-03-22drm/i915/hdcp: mst streams type1 capability checkAnshuman Gupta1-1/+16
It requires to check streams type1 capability in mst topology by checking Rxinfo instead connector HDCP2.x capability in order to enforce type0 stream encryption in a mix of HDCP {1.x,2.x} mst topology. Rxcaps always shows HDCP 2.x capability of immediate downstream connector. Let's use Rxinfo HDCP1_DEVICE_DOWNSTREAM bit to detect a HDCP {1.x,2.x} mix mst topology. Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210319091732.17547-1-anshuman.gupta@intel.com
2021-01-22drm/i915/hdcp: Fix uninitialized symbolAnshuman Gupta1-10/+10
Move (num_hdcp_streams > 0) condition to stream_encryption() code block, where it actually belongs. This fixes the static analysis error of uninitialized symbol 'ret'. v2: - return 0 as the return value is already checked. [Ankit] Cc: Ramalingam C <ramalingam.c@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210120103032.15198-1-anshuman.gupta@intel.com
2021-01-22drm/i915/hdcp: Fix WARN_ON(data->k > INTEL_NUM_PIPES)Anshuman Gupta1-0/+2
Initialize no. of streams transmitted on a port to zero such that intel_hdcp_required_content_stream() can prepared the content stream after subsequemt attmept to enable hdcp after a HDCP failure. v2: - Initialize k at top level instead of else branch. [Jani] Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210119064655.1605-2-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Enable HDCP 2.2 MST supportAnshuman Gupta1-1/+1
Enable HDCP 2.2 MST support till Gen12. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-20-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Configure HDCP2.2 MST steram encryption statusAnshuman Gupta1-1/+50
Authenticate and enable port encryption only once for an active HDCP 2.2 session, once port is authenticated and encrypted enable encryption for each stream that requires encryption on this port. Similarly disable the stream encryption for each encrypted stream, once all encrypted stream encryption is disabled, disable the port HDCP encryption and deauthenticate the port. v2: - Add connector details in drm_err. [Ram] - 's/port_auth/hdcp_auth_status'. [Ram] - Added a debug print for stream enc. v3: - uniformity for connector detail in DMESG. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-19-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Pass connector to check_2_2_linkAnshuman Gupta1-1/+1
This requires for HDCP 2.2 MST check link. As for DP/HDMI shims check_2_2_link retrieves the connector from dig_port, this is not sufficient or DP MST connector, there can be multiple DP MST topology connector associated with same dig_port. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: MST streams support in hdcp port_dataAnshuman Gupta1-14/+99
Add support for multiple mst stream in hdcp port data which will be used by RepeaterAuthStreamManage msg and HDCP 2.2 security f/w for m' validation. Security f/w doesn't have any provision to mark the stream_type for each stream separately, it just take single input of stream_type while authenticating the port and applies the same stream_type to all streams. So driver mark each stream_type with common highest supported content type for all streams in DP MST Topology. Security f/w supports RepeaterAuthStreamManage msg and m' validation only once during port authentication and encryption. Though it is not compulsory, security fw should support dynamic update of content_type and should support RepeaterAuthStreamManage msg and m' validation whenever required. v2: - Init the hdcp port data k for HDMI/DP SST stream. v3: - Cosmetic changes. [Uma] v4: - 's/port_auth/hdcp_port_auth'. [Ram] - Commit log improvement. v5: - Comment and commit log improvement. [Ram] v6: - Check first connector connected status before intel_encoder_is_mst to avoid any NULL pointer dereference. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Tested-by: Juston Li <juston.li@intel.com> Acked-by: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-15-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Encapsulate hdcp_port_data to dig_portAnshuman Gupta1-22/+34
hdcp_port_data is specific to a port on which HDCP encryption is getting enabled, so encapsulate it to intel_digital_port. This will be required to enable HDCP 2.2 stream encryption. v2: - 's/port_data/hdcp_port_data'. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-12-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Pass dig_port to intel_hdcp_initAnshuman Gupta1-5/+7
Pass dig_port as an argument to intel_hdcp_init() and intel_hdcp2_init(). This will be required for HDCP 2.2 stream encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Configure HDCP1.4 MST steram encryption statusAnshuman Gupta1-13/+25
Enable HDCP 1.4 DP MST stream encryption. Enable stream encryption once encryption is enabled on the DP transport driving the link for each stream which has requested encryption. Disable stream encryption for each stream that no longer requires encryption before disabling HDCP encryption on the link. v2: - Added debug print for stream encryption. - Disable the hdcp on port after disabling last stream encryption. v3: - Cosmetic change, removed the value less comment. [Uma] v4: - Split the Gen12 HDCP enablement patch. [Ram] - Add connector details in drm_err. v5: - uniformity for connector detail in DMESG. [Ram] - comments improvement. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-9-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Move HDCP enc status timeout to headerAnshuman Gupta1-5/+4
DP MST stream encryption status requires time of a link frame in order to change its status, but as there were some HDCP encryption timeout observed earlier, it is safer to use ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too, it requires to move the macro to a header. It will be used by both HDCP{1.x,2.x} stream status timeout. Related: 'commit 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt status change")' Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-7-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: DP MST transcoder for link and streamAnshuman Gupta1-4/+11
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine instances lies in Transcoder instead of DDI as in Gen11. This requires hdcp driver to use mst_master_transcoder for link authentication and stream transcoder for stream encryption separately. This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST on Gen12. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-6-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: No HDCP when encoder is't initializedAnshuman Gupta1-0/+6
There can be situation when DP MST connector is created without mst modeset being done, in those cases connector->encoder will be NULL. MST connector->encoder initializes after modeset. Don't enable HDCP in such cases to prevent any crash. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Juston Li <juston.li@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-5-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Get conn while content_type changedAnshuman Gupta1-0/+1
Get DRM connector reference count while scheduling a prop work to avoid any possible destroy of DRM connector when it is in DRM_CONNECTOR_REGISTERED state. Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors") Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Update CP property in update_pipeAnshuman Gupta1-0/+8
When crtc state need_modeset is true it is not necessary it is going to be a real modeset, it can turns to be a fastset instead of modeset. This turns content protection property to be DESIRED and hdcp update_pipe left with property to be in DESIRED state but actual hdcp->value was ENABLED. This issue is caught with DP MST setup, where we have multiple connector in same DP_MST topology. When disabling HDCP on one of DP MST connector leads to set the crtc state need_modeset to true for all other crtc driving the other DP-MST topology connectors. This turns up other DP MST connectors CP property to be DESIRED despite the actual hdcp->value is ENABLED. Above scenario fails the DP MST HDCP IGT test, disabling HDCP on one MST stream should not cause to disable HDCP on another MST stream on same DP MST topology. v2: - Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED WARN_ON. v3: - Commit log improvement. [Uma] - Added a comment before scheduling prop_work. [Uma] Fixes: 33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal state") Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com
2020-09-24drm/i915: dont retry stream management at seq_num_m roll overRamalingam C1-5/+10
When roll over detected for seq_num_m, we shouldn't continue with stream management with rolled over value. So we are terminating the stream management retry, on roll over of the seq_num_m. v2: using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman] v3: dev_priv is used as i915 [JaniN] v4: roll over is detected at the start of the stream management. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> [v3] Tested-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-3-anshuman.gupta@intel.com
2020-09-24drm/i915: terminate reauth at stream management failureRamalingam C1-29/+47
As per the HDCP2.2 compliance test 1B-10 expectation, when stream management for a repeater fails, we retry thrice and when it fails in all retries, HDCP2.2 reauthentication aborted at kernel. v2: seq_num_m++ is extended for steam management failures too.[Anshuman] v3: use drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman] v4: dev_priv is used as i915 [JaniN] v5: Few improvisements are done [Sean] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-2-anshuman.gupta@intel.com
2020-09-01drm/i915: Add HDCP 1.4 support for MST connectorsSean Paul1-1/+1
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over MST. Everything except for toggling the HDCP signalling and HDCP 2.2 support is the same as the DP case, so we'll re-use those callbacks Cc: Juston Li <juston.li@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-sean@poorly.run #v7 Changes in v2: -Toggle HDCP from encoder disable/enable -Don't disable HDCP on MST connector destroy, leave that for encoder disable, just ensure the check_work routine isn't running any longer Changes in v3: -Place the shim in the new intel_dp_hdcp.c file (Ville) Changes in v4: -Actually use the mst shim for mst connections (Juston) -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted Changes in v5: -Add sleep on disable signalling to match hdmi delay Changes in v6: -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I don't have hardware to test it Changes in v7: -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-18-sean@poorly.run
2020-09-01drm/i915: Add connector to hdcp_shim->check_link()Sean Paul1-1/+1
Currently we derive the connector from digital port in check_link(). For MST, this isn't sufficient since the digital port passed into the function can have multiple connectors downstream. This patch adds connector to the check_link() arguments so we have it when we need it. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-sean@poorly.run #v7 Changes in v4: -Added to the set Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-15-sean@poorly.run
2020-09-01drm/i915: Plumb port through hdcp initSean Paul1-5/+6
This patch plumbs port through hdcp init instead of relying on intel_attached_encoder() to return a non-NULL encoder which won't work for MST connectors. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-sean@poorly.run #v7 Changes in v5: -Added to the set Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-14-sean@poorly.run
2020-09-01drm/i915: Don't fully disable HDCP on a port if multiple pipes are using itSean Paul1-0/+33
This patch is required for HDCP over MST. If a port is being used for multiple HDCP streams, we don't want to fully disable HDCP on a port if one of them is disabled. Instead, we just disable the HDCP signalling on that particular pipe and exit early. The last pipe to disable HDCP will also bring down HDCP on the port. In order to achieve this, we need to keep a refcount in intel_digital_port and protect it using a new hdcp_mutex. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-sean@poorly.run #v7 Changes in v2: -Move the toggle_signalling call into _intel_hdcp_disable so it's called from check_work Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Split minor intel_hdcp_disable refactor into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-10-sean@poorly.run
2020-09-01drm/i915: Clean up intel_hdcp_disableSean Paul1-9/+10
Add an out label and un-indent hdcp disable in preparation for hdcp_mutex. No functional changes Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-sean@poorly.run #v7 Changes in v7: -Split into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-9-sean@poorly.run
2020-09-01drm/i915: Protect workers against disappearing connectorsSean Paul1-5/+39
This patch adds some protection against connectors being destroyed before the HDCP workers are finished. For check_work, we do a synchronous cancel after the connector is unregistered which will ensure that it is finished before destruction. In the case of prop_work, we can't do a synchronous wait since it needs to take connection_mutex which could cause deadlock. Instead, we'll take a reference on the connector when scheduling prop_work and give it up once we're done. Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -Change the WARN_ON condition in intel_hdcp_cleanup to allow for initializing connectors as well Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-8-sean@poorly.run
2020-09-01drm/i915: Factor out hdcp->value assignmentsSean Paul1-21/+46
This is a bit of housecleaning for a future patch. Instead of sprinkling hdcp->value assignments and prop_work scheduling everywhere, introduce a function to do it for us. Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -Rebased on top of drm_* logging changes Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-7-sean@poorly.run
2020-09-01drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signallingSean Paul1-7/+8
Instead of using intel_dig_port's encoder pipe to determine which transcoder to toggle signalling on, use the cpu_transcoder field already stored in intel_hdmi. This is particularly important for MST. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -s/hdcp/hdmi/ in commit msg (Ram) Changes in v4: -Rebased on intel_de_(read|write) change Changes in v5: -Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0 Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-6-sean@poorly.run
2020-09-01drm/i915: Clear the repeater bit on HDCP disableSean Paul1-0/+6
On HDCP disable, clear the repeater bit. This ensures if we connect a non-repeater sink after a repeater, the bit is in the state we expect. Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -None I had previously agreed that clearing the rep_ctl bits on enable would also be a good idea. However when I committed that idea to code, it didn't look right. So let's rely on enables and disables being paired and everything outside of that will be considered a bug Changes in v4: -s/I915_(READ|WRITE)/intel_de_(read|write)/ Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run
2020-09-01drm/i915: Fix sha_text population codeSean Paul1-6/+20
This patch fixes a few bugs: 1- We weren't taking into account sha_leftovers when adding multiple ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with the beginning of ksv[j] 2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was being placed on the wrong half of sha_text, overlapping the leftover ksv value 3- In the sha_leftovers == 2 case, we need to manually terminate the byte stream with 0x80 since the hardware doesn't have enough room to add it after writing M0 The upside is that all of the HDCP supported HDMI repeaters I could find on Amazon just strip HDCP anyways, so it turns out to be _really_ hard to hit any of these cases without an MST hub, which is not (yet) supported. Oh, and the sha_leftovers == 1 case works perfectly! Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -Rebased on intel_de_write changes Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run
2020-08-26drm/i915/hdcp: No direct access to power_well descAnshuman Gupta1-12/+3
HDCP code doesn't require to access power_well internal stuff, instead it should use the intel_display_power_well_is_enabled() to get the status of desired power_well. No functional change. v2: - used with_intel_runtime_pm instead of get/put. [Jani] v3: - rebased. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-3-anshuman.gupta@intel.com
2020-08-26drm/i915/hdcp: Add update_pipe early returnAnshuman Gupta1-2/+6
Currently intel_hdcp_update_pipe() is also getting called for non-hdcp connectors and get through its conditional code flow, which is completely unnecessary for non-hdcp connectors, therefore it make sense to have an early return. No functional change. v2: - rebased. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-2-anshuman.gupta@intel.com
2020-07-08drm/i915/hdcp: Fix the return handling of drm_hdcp_check_ksvs_revokedRamalingam C1-4/+4
drm_hdcp_check_ksvs_revoked() returns the number of revoked keys and error codes when the SRM parsing is failed. Errors in SRM parsing can't affect the HDCP auth, hence with this patch, I915 will look out for revoked key count alone. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200429134555.22106-1-ramalingam.c@intel.com
2020-07-08drm/i915/hdcp: Update CP as per the kernel internal stateAnshuman Gupta1-4/+23
Content Protection property should be updated as per the kernel internal state. Let's say if Content protection is disabled by userspace, CP property should be set to UNDESIRED so that reauthentication will not happen until userspace request it again, but when kernel disables the HDCP due to any DDI disabling sequences like modeset/DPMS operation, kernel should set the property to DESIRED, so that when opportunity arises, kernel will start the HDCP authentication on its own. Somewhere in the line, state machine to set content protection to DESIRED from kernel was broken and IGT coverage was missing for it. This patch fixes it. v2: - Fixing hdcp CP state in connector atomic check function intel_hdcp_atomic_check(). [Maarten] This will require to check hdcp->value in intel_hdcp_update_pipe() in order to avoid enabling hdcp, if it was already enabled. v3: - Rebased. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/350962/?series=72664&rev=2 #v1 Link: https://patchwork.freedesktop.org/patch/359396/?series=72251&rev=3 #v2 Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630082048.22308-1-anshuman.gupta@intel.com
2020-07-02drm/i915/display: prefer dig_port to reference intel_digital_portLucas De Marchi1-59/+59
We have a mix of dport, intel_dport, intel_dig_port and dig_port to reference a intel_digital_port struct. Numbers are around 5 intel_dport 36 dport 479 intel_dig_port 352 dig_port Since we already removed the intel_ prefix from most of our other structs, do the same here and prefer dig_port. v2: rename everything in i915, not just a few display sources and reword commit message (from Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701045054.23357-1-lucas.demarchi@intel.com
2020-06-02drm/i915: Identify Cometlake platformChris Wilson1-2/+5
Cometlake is a small refresh of Coffeelake, but since we have found out a difference in the plaforms, we need to identify them as separate platforms. Since we previously took Coffeelake/Cometlake as identical, update all IS_COFFEELAKE() to also include IS_COMETLAKE(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602140541.5481-1-chris@chris-wilson.co.uk
2020-04-21drm/i915: drop a bunch of superfluous inlinesJani Nikula1-14/+9
Remove a number of inlines from .c files, and let the compiler decide what's best. There's more to do, but need to start somewhere, and need to start setting the example. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200420140438.14672-2-jani.nikula@intel.com
2020-04-03drm/i915: Pass atomic state to encoder hooksVille Syrjälä1-1/+2
We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-05 05:52:12 +0000