public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ramalingam C <ramalingam.c@intel.com>
To: Sean Paul <seanpaul@chromium.org>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch
Date: Tue, 27 Feb 2018 17:08:30 +0530	[thread overview]
Message-ID: <88e5d0ab-db45-848e-4aa5-90a69b094950@intel.com> (raw)
In-Reply-To: <20180226173723.GV223881@art_vandelay>



On Monday 26 February 2018 11:07 PM, Sean Paul wrote:
> On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote:
>> 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.
> "R0' must be available for the HDCP Transmitter to read within 100
> milliseconds from the time that the HDCP Transmitter finishes writing Aksv to
> the video receiver."
>
> 100ms is a minimum, waiting for 300ms is quite generous.

Yes Even with this patch, total wait time for R0 will be 300 mSec only. Splitted into 3 100mSec wait one in each loop.
First loop waits for 100mSec from AKSV write, second loop waits for 200mSec from AKSV write and
third is 300mSec from AKSV write.

This way if a monitor prepares the R0 in 100 mSec, we wont simply wait for 300mSec.
And also we fulfill DP compliance expectation of three attempts to read valid R0.

--Ram

>
> The retry is to account for link errors, so there's no need to include the wait
> in the retry loop.
>
> Sean
>
>> DP CTS Test: 1A-06.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_hdcp.c | 34 ++++++++++++++++++++++------------
>>   1 file changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
>> index 14ca5d3057a7..730681d2dbfb 100644
>> --- a/drivers/gpu/drm/i915/intel_hdcp.c
>> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
>> @@ -496,25 +496,35 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
>>   	}
>>   
>>   	/*
>> -	 * Wait for R0' to become available. The spec says 100ms from Aksv, but
>> -	 * some monitors can take longer than this. We'll set the timeout at
>> -	 * 300ms just to be sure.
>> +	 * Wait for R0' to become available. The spec says minimum 100ms from
>> +	 * Aksv, but some monitors can take longer than this. So we are
>> +	 * combinely waiting for 300mSec just to be sure in case of HDMI.
>> +	 * DP HDCP Spec mandates the two more reattempt to read R0, incase
>> +	 * of R0 mismatch.
>>   	 *
>>   	 * On DP, there's an R0_READY bit available but no such bit
>>   	 * exists on HDMI. Since the upper-bound is the same, we'll just do
>>   	 * the stupid thing instead of polling on one and not the other.
>>   	 */
>> -	wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
>>   
>> -	ri.reg = 0;
>> -	ret = shim->read_ri_prime(intel_dig_port, ri.shim);
>> -	if (ret)
>> -		return ret;
>> -	I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
>> +	tries = 3;
>> +	for (i = 0; i < tries; i++) {
>> +		wait_remaining_ms_from_jiffies(r0_prime_gen_start,
>> +					       100 * (i + 1));
>>   
>> -	/* Wait for Ri prime match */
>> -	if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
>> -		     (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
>> +		ri.reg = 0;
>> +		ret = shim->read_ri_prime(intel_dig_port, ri.shim);
>> +		if (ret)
>> +			return ret;
>> +		I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
>> +
>> +		/* Wait for Ri prime match */
>> +		if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
>> +		    (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
>> +			break;
>> +	}
>> +
>> +	if (i == tries) {
>>   		DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
>>   			  I915_READ(PORT_HDCP_STATUS(port)));
>>   		return -ETIMEDOUT;
>> -- 
>> 2.7.4
>>

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

  reply	other threads:[~2018-02-27 11:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 17:12 [PATCH 0/5] HDCP1.4 fixes Ramalingam C
2018-02-26 17:12 ` [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch Ramalingam C
2018-02-26 17:37   ` Sean Paul
2018-02-27 11:38     ` Ramalingam C [this message]
2018-02-26 17:12 ` [PATCH 2/5] drm/i915: read Vprime thrice incase " Ramalingam C
2018-02-26 17:40   ` Sean Paul
2018-02-27 12:32   ` [PATCH v2] " Ramalingam C
2018-02-26 17:12 ` [PATCH 3/5] drm/i915: Check hdcp key loadability Ramalingam C
2018-02-26 17:45   ` Sean Paul
2018-02-26 17:12 ` [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK Ramalingam C
2018-02-26 17:52   ` Sean Paul
2018-02-27 14:36     ` Ramalingam C
2018-02-26 17:12 ` [PATCH 5/5] drm/i915: Move hdcp msg detection into shim Ramalingam C
2018-02-26 18:01   ` Sean Paul
2018-02-27 11:20     ` Ramalingam C
2018-02-26 22:50   ` [Intel-gfx] " Chris Wilson
2018-03-08  6:29     ` Ramalingam C
2018-02-26 17:44 ` ✓ Fi.CI.BAT: success for HDCP1.4 fixes Patchwork
2018-02-26 22:21 ` ✓ Fi.CI.IGT: " Patchwork
2018-02-26 23:24 ` [PATCH 0/5] " Rodrigo Vivi
2018-02-27 11:11   ` Ramalingam C
2018-02-27 13:28 ` ✗ Fi.CI.BAT: failure for HDCP1.4 fixes (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88e5d0ab-db45-848e-4aa5-90a69b094950@intel.com \
    --to=ramalingam.c@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=seanpaul@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox