[PATCH 0/4] HDCP1.4 fixes

[PATCH 0/4] HDCP1.4 fixes

[Ramalingam C]

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(-)

-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[Ramalingam C]

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);
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/4] drm/i915: Fix platform coverage for HDCP1.4

[Ramalingam C]

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,
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/4] drm/i915: debug log for REPLY_ACK missing

[Ramalingam C]

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,
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/i915: Increase timeout for Encrypt status change

[Ramalingam C]

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;
 	}
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[Ville Syrjälä]

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

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[C, Ramalingam]

[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 3172 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[Ramalingam C]

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);
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/4] HDCP1.4 fixes

[C, Ramalingam]

[-- Attachment #1.1: Type: text/plain, Size: 680 bytes --]

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(-)
>

[-- Attachment #1.2: Type: text/html, Size: 1036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[Sean Paul]

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))) {
>  		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

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/4] drm/i915: Fix platform coverage for HDCP1.4

[Sean Paul]

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

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/4] drm/i915: debug log for REPLY_ACK missing

[Sean Paul]

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

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 4/4] drm/i915: Increase timeout for Encrypt status change

[Sean Paul]

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)) {
>  		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;
>  	}
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel