Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
v4:
Commit msg is rephrased [Uma]
v5:
Comment for mutex definition.
v6:
hdcp_ prefix from all intel_hdcp members are removed [Sean Paul]
inline function intel_hdcp_to_connector is defined [Sean Paul]
v7:
%s/uint64_t/u64
v8:
Rebased
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540806351-7137-2-git-send-email-ramalingam.c@intel.com
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of these objects their corresponding
i915_power_well_desc object.
v2:
- Fix checkpatch warnings about missing param name in fn declaration and
lines over 80 chars. (Paulo)
- Move check for unique IDs to __set_power_wells().
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Fixed checkpatch warn in __set_power_wells()]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
This patch is needed for DP HDCP1.4 CTS Test: 1A-06.
v2:
No Change
v3:
Comment on R0 retry is moved closer to the code[Seanpaul]
v4:
Removing unwanted noise introduced in v3.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522669822-2508-1-git-send-email-ramalingam.c@intel.com
DP HDCP1.4 spec mandates that An can be written to panel only after
detecting the panel's hdcp capability.
For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
For HDMI valid BKSV indicates the panel's hdcp capability.
For HDMI it is optional to detect the panel's hdcp capability before
An Write.
v2:
Added comments explaining the need for action [Seanpaul].
Made panel's hdcp capability detection optional for hdmi [Seanpaul].
Defined a func for reading bcaps for DP [Seanpaul].
v3:
Removed the NULL initialization [Seanpaul].
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-7-git-send-email-ramalingam.c@intel.com
HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.
This patch adds the above mentioned re-read for bksv.
v2:
Rephrased the commit msg [Seanpaul]
v3:
do-while to for-loop [Seanpaul]
v4:
retry only if bksv is invalid and no error msg on each attempt
[Seanpaul]
v5:
Correcting the return value [Seanpaul].
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1517851922-30547-1-git-send-email-ramalingam.c@intel.com
If a HDCP repeater is detected with zero downstream devices,
HDCP spec approves either of below actions:
1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
on success, continue encryption.
Since disable encryption is agreed, repeater is not expected to have its
own display. So there is no consumption of the display content in such
setup.
Hence, incase of repeater with zero device count, this patch fails the
HDCP authentication and stops the HDCP encryption.
v2:
Rephrased commit msg and added comments in code [Seanpaul]
v3:
No changes. Added Reviewed-by tag.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-3-git-send-email-ramalingam.c@intel.com
We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.
This patch ensures that, when hdcp authentication fails, HDCP encryption
and signalling is turned off.
v2:
Dropped connector ref passing to auth [Seanpaul]
Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul]
v3:
No Changes. Added the Reveiwed-by tag.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1517609350-10698-2-git-send-email-ramalingam.c@intel.com
HDCP compliant Repeaters can support max of 127 devices and max
depth of 7 for downstream topology.
If these max limits are exceeded, repeater will set the
topology error flags MAX_CASCADE_EXCEEDED and/or MAX_DEVS_EXCEEDED
in Bstatus followed by asserting READY/CP_IRQ for HDCP transmitter.
This patch check for these error flags as soon as READY bit is asserted.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
[seanpaul fixed checkpatch alignment issue]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-5-git-send-email-ramalingam.c@intel.com
Second stage of HDCP authentication starts at CP_IRQ or at the
assertion of READY bit from Repeater.
Till then repeater will be authenticating with its downstream devices.
So authenticated device count, depth and ksv_list readable from
repeaters are valid only after assertion of READY/CP_IRQ.
This patch makes sure that READY is polled before reading any
topology information.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-4-git-send-email-ramalingam.c@intel.com
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.
Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.
Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)
Changes in v4:
- Remove SKL_ prefix from most register names (Daniel)
- Move enable/disable back to modeset path (Daniel)
- s/get_random_long/get_random_u32/ (Daniel)
- Remove mode_config.mutex lock in prop_work (Daniel)
- Add intel_hdcp_init to handle init of conn components (Daniel)
- Actually check return value of attach_property
- Check Bksv is valid before trying to authenticate (Ram)
Changes in v5:
- checkpatch whitespace changes
- s/DRM_MODE_CONTENT_PROTECTION_OFF/DRM_MODE_CONTENT_PROTECTION_UNDESIRED/
- Fix ksv list wait timeout (actually wait 5s)
- Increase the R0 timeout to 300ms (Ram)
Changes in v6:
- SPDX license
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ramalingam C <ramalingm.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-6-seanpaul@chromium.org
