Couple of more HDCP1.4 fixes on - Key load process for CFL - Encryption status change time - debug log addition - active platform coverage
Ramalingam C (4): drm/i915: Fix GEN9 HDCP1.4 key load process drm/i915: Fix platform coverage for HDCP1.4 drm/i915: debug log for REPLY_ACK missing drm/i915: Increase timeout for Encrypt status change
drivers/gpu/drm/i915/intel_dp.c | 6 +++++- drivers/gpu/drm/i915/intel_hdcp.c | 17 ++++++++++------- 2 files changed, 15 insertions(+), 8 deletions(-)
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. Instead of listing all the platforms for this method, adopted this method for all Gen9 platforms with exceptions. In this way we need not extent check for new GEN9 platforms like CFL.
Signed-off-by: Ramalingam C ramalingam.c@intel.com --- drivers/gpu/drm/i915/intel_hdcp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index 1bf487f94254..beacfbb6e5e1 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv) /* * Initiate loading the HDCP key from fuses. * - * BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL - * differ in the key load trigger process from other platforms. + * BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9 + * platforms except BXT and GLK, differ in the key load trigger process + * from other platforms. */ - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) { + if (IS_GEN9(dev_priv) && + (!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) { mutex_lock(&dev_priv->pcu_lock); ret = sandybridge_pcode_write(dev_priv, SKL_PCODE_LOAD_HDCP_KEYS, 1);
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. Instead of listing all the platforms for this method, adopted this method for all Gen9 platforms with exceptions. In this way we need not extent check for new GEN9 platforms like CFL.
Signed-off-by: Ramalingam C ramalingam.c@intel.com
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index 1bf487f94254..beacfbb6e5e1 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv) /* * Initiate loading the HDCP key from fuses. *
* BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL* differ in the key load trigger process from other platforms.
* BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9* platforms except BXT and GLK, differ in the key load trigger process* from other platforms.
- if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
- if (IS_GEN9(dev_priv) &&
(!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {
IS_GEN9_BC()
mutex_lock(&dev_priv->pcu_lock); ret = sandybridge_pcode_write(dev_priv, SKL_PCODE_LOAD_HDCP_KEYS, 1);-- 2.7.4
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 11/27/2018 8:45 PM, Ville Syrjälä wrote:
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. Instead of listing all the platforms for this method, adopted this method for all Gen9 platforms with exceptions. In this way we need not extent check for new GEN9 platforms like CFL.
Signed-off-by: Ramalingam C ramalingam.c@intel.com
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index 1bf487f94254..beacfbb6e5e1 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv) /* * Initiate loading the HDCP key from fuses. *
* BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL* differ in the key load trigger process from other platforms.
* BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9* platforms except BXT and GLK, differ in the key load trigger process* from other platforms.
- if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
- if (IS_GEN9(dev_priv) &&
(!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {IS_GEN9_BC()
Bspec doesn't state anything about BC/LP. They have mentioned GEN9+ with BXT, CNL, ICL excluded. So I am inferring that this method is only for Gen9 excluding BXT and GLK (verified).
Remaining platforms are SKL, KBL, and CFL. IS_GEN9_BC() will filter them easily. unless we find otherwise, we can use this. Thanks Ville.
--Ram
mutex_lock(&dev_priv->pcu_lock); ret = sandybridge_pcode_write(dev_priv, SKL_PCODE_LOAD_HDCP_KEYS, 1);-- 2.7.4
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. So all GEN9_BC platforms will use the GT Driver Mailbox interface for HDCP1.4 key load.
v2: Using the IS_GEN9_BC for filtering the platforms [Ville]
Signed-off-by: Ramalingam C ramalingam.c@intel.com --- drivers/gpu/drm/i915/intel_hdcp.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index 1bf487f94254..c16bffcce3b0 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -157,10 +157,11 @@ static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv) /* * Initiate loading the HDCP key from fuses. * - * BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL - * differ in the key load trigger process from other platforms. + * BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9 + * platforms except BXT and GLK, differ in the key load trigger process + * from other platforms. So GEN9_BC uses the GT Driver Mailbox i/f. */ - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) { + if (IS_GEN9_BC(dev_priv)) { mutex_lock(&dev_priv->pcu_lock); ret = sandybridge_pcode_write(dev_priv, SKL_PCODE_LOAD_HDCP_KEYS, 1);
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. Instead of listing all the platforms for this method, adopted this method for all Gen9 platforms with exceptions. In this way we need not extent check for new GEN9 platforms like CFL.
Signed-off-by: Ramalingam C ramalingam.c@intel.com
Reviewed-by: Sean Paul sean@poorly.run
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index 1bf487f94254..beacfbb6e5e1 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private *dev_priv) /* * Initiate loading the HDCP key from fuses. *
* BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL* differ in the key load trigger process from other platforms.
* BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9* platforms except BXT and GLK, differ in the key load trigger process* from other platforms.
- if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
- if (IS_GEN9(dev_priv) &&
(!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {-- 2.7.4
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
HDCP1.4 is enabled and validated only on GEN9+ platforms.
Signed-off-by: Ramalingam C ramalingam.c@intel.com --- drivers/gpu/drm/i915/intel_hdcp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index beacfbb6e5e1..bd60d0e7bbfa 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -770,8 +770,7 @@ static void intel_hdcp_prop_work(struct work_struct *work) bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port) { /* PORT E doesn't have HDCP, and PORT F is disabled */ - return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) && - !IS_CHERRYVIEW(dev_priv) && port < PORT_E); + return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E); }
int intel_hdcp_init(struct intel_connector *connector,
On Tue, Nov 27, 2018 at 07:32:57PM +0530, Ramalingam C wrote:
HDCP1.4 is enabled and validated only on GEN9+ platforms.
Signed-off-by: Ramalingam C ramalingam.c@intel.com
Reviewed-by: Sean Paul sean@poorly.run
drivers/gpu/drm/i915/intel_hdcp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index beacfbb6e5e1..bd60d0e7bbfa 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -770,8 +770,7 @@ static void intel_hdcp_prop_work(struct work_struct *work) bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port) { /* PORT E doesn't have HDCP, and PORT F is disabled */
- return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
!IS_CHERRYVIEW(dev_priv) && port < PORT_E);
- return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);
}
int intel_hdcp_init(struct intel_connector *connector,
2.7.4
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing for aksv write. This helps to locate the possible non responding DP HDCP sinks.
Signed-off-by: Ramalingam C ramalingam.c@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 70ae3d57316b..18e3a5a3d873 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5390,7 +5390,11 @@ int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port, }
reply = (rxbuf[0] >> 4) & DP_AUX_NATIVE_REPLY_MASK; - return reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO; + ret = reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO; + if (ret) + DRM_DEBUG_KMS("Aksv write: DP_AUX_NATIVE_REPLY_ACK missing\n"); + + return ret; }
static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
On Tue, Nov 27, 2018 at 07:32:58PM +0530, Ramalingam C wrote:
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing for aksv write. This helps to locate the possible non responding DP HDCP sinks.
Signed-off-by: Ramalingam C ramalingam.c@intel.com
drivers/gpu/drm/i915/intel_dp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 70ae3d57316b..18e3a5a3d873 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5390,7 +5390,11 @@ int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port, }
reply = (rxbuf[0] >> 4) & DP_AUX_NATIVE_REPLY_MASK;
- return reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
- ret = reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
- if (ret)
DRM_DEBUG_KMS("Aksv write: DP_AUX_NATIVE_REPLY_ACK missing\n");
This is pretty hard to read. Could you please change to:
if (reply != DP_AUX_NATIVE_REPLY_ACK) { DRM_DEBUG_KMS("Aksv write: no DP_AUX_NATIVE_REPLY_ACK %x\n", reply); return -EIO } return 0;
With this change,
Reviewed-by: Sean Paul sean@poorly.run
- return ret;
}
static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
2.7.4
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
At enable/disable of the HDCP encryption, for encryption status change we need minimum one frame duration. And we might program this bit any point(start/End) in the previous frame.
With 20mSec, observed the timeout for change in encryption status. Since this is not time critical operation and we need to hold on until the status is changed, fixing the timeout to 50mSec. (Based on trial and error method!)
Signed-off-by: Ramalingam C ramalingam.c@intel.com --- drivers/gpu/drm/i915/intel_hdcp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index bd60d0e7bbfa..156b14d19e09 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -15,6 +15,7 @@ #include "i915_reg.h"
#define KEY_LOAD_TRIES 5 +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
static bool intel_hdcp_is_ksv_valid(u8 *ksv) @@ -638,7 +639,8 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
/* Wait for encryption confirmation */ if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), - HDCP_STATUS_ENC, HDCP_STATUS_ENC, 20)) { + HDCP_STATUS_ENC, HDCP_STATUS_ENC, + TIME_FOR_ENCRYPT_STATUS_CHANGE)) { DRM_ERROR("Timed out waiting for encryption\n"); return -ETIMEDOUT; } @@ -668,7 +670,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
I915_WRITE(PORT_HDCP_CONF(port), 0); if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0, - 20)) { + TIME_FOR_ENCRYPT_STATUS_CHANGE)) { DRM_ERROR("Failed to disable HDCP, timeout clearing status\n"); return -ETIMEDOUT; }
On Tue, Nov 27, 2018 at 07:32:59PM +0530, Ramalingam C wrote:
At enable/disable of the HDCP encryption, for encryption status change we need minimum one frame duration. And we might program this bit any point(start/End) in the previous frame.
With 20mSec, observed the timeout for change in encryption status. Since this is not time critical operation and we need to hold on until the status is changed, fixing the timeout to 50mSec. (Based on trial and error method!)
Signed-off-by: Ramalingam C ramalingam.c@intel.com
drivers/gpu/drm/i915/intel_hdcp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c index bd60d0e7bbfa..156b14d19e09 100644 --- a/drivers/gpu/drm/i915/intel_hdcp.c +++ b/drivers/gpu/drm/i915/intel_hdcp.c @@ -15,6 +15,7 @@ #include "i915_reg.h"
#define KEY_LOAD_TRIES 5 +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS please
with that fixed,
Reviewed-by: Sean Paul sean@poorly.run
static bool intel_hdcp_is_ksv_valid(u8 *ksv) @@ -638,7 +639,8 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
/* Wait for encryption confirmation */ if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port),
HDCP_STATUS_ENC, HDCP_STATUS_ENC, 20)) {
HDCP_STATUS_ENC, HDCP_STATUS_ENC,TIME_FOR_ENCRYPT_STATUS_CHANGE)) {@@ -668,7 +670,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
I915_WRITE(PORT_HDCP_CONF(port), 0); if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
20)) {
TIME_FOR_ENCRYPT_STATUS_CHANGE)) {-- 2.7.4
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Sean and Daniel,
Could you please help me with the review these changes?
--Ram
On 11/27/2018 7:32 PM, Ramalingam C wrote:
Couple of more HDCP1.4 fixes on
- Key load process for CFL
- Encryption status change time
- debug log addition
- active platform coverage
Ramalingam C (4): drm/i915: Fix GEN9 HDCP1.4 key load process drm/i915: Fix platform coverage for HDCP1.4 drm/i915: debug log for REPLY_ACK missing drm/i915: Increase timeout for Encrypt status change
drivers/gpu/drm/i915/intel_dp.c | 6 +++++- drivers/gpu/drm/i915/intel_hdcp.c | 17 ++++++++++------- 2 files changed, 15 insertions(+), 8 deletions(-)
dri-devel@lists.freedesktop.org
-
C, Ramalingam -
Ramalingam C
-
Sean Paul -
Ville Syrjälä