public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Todd Previte <tprevite@gmail.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 07/11] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
Date: Tue, 07 Apr 2015 11:47:27 -0700	[thread overview]
Message-ID: <5524263F.2020106@gmail.com> (raw)
In-Reply-To: <CA+gsUGQ5c7ZC775FrzcZibF-sKmCa7S+Nh1f+viHH8-W71qv0g@mail.gmail.com>


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



On 4/7/15 7:29 AM, Paulo Zanoni wrote:
> 2015-04-06 23:11 GMT-03:00 Todd Previte <tprevite@gmail.com>:
>> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
>> device must attempt at least 7 times to read the EDID when it receives an
>> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
>> or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
>> since there are native defers interspersed with the I2C defers which
>> results in less than 7 EDID read attempts.
>>
>> The solution is to decrement the retry counter when an I2C DEFER is returned
>> such that another read attempt will be made. This situation should normally
>> only occur in compliance testing, however, as a worse case real-world
>> scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
>> for a single transaction to complete. The net result is a slightly slower
>> response to an EDID read that shouldn't significantly impact overall
>> performance.
>>
>> V2:
>> - Added a check on the number of I2C Defers to limit the number
>>    of times that the retries variable will be decremented. This
>>    is to address review feedback regarding possible infinite loops
>>    from misbehaving sink devices.
>>
>> Signed-off-by: Todd Previte <tprevite@gmail.com>
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>>   drivers/gpu/drm/drm_dp_helper.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
>> index 79968e3..23025cf 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -469,6 +469,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
>>                  case DP_AUX_I2C_REPLY_DEFER:
>>                          DRM_DEBUG_KMS("I2C defer\n");
>>                          aux->i2c_defer_count++;
>> +                       /* DP Compliance Test 4.2.2.5 Requirement:
>> +                        * Must have at least 7 retries for I2C defers on the
>> +                        * transaction to pass this test
>> +                        */
>> +                       if (aux->i2c_defer_count < 8)
> I don't think this is the way to go. During normal
> (non-compliance-testing) operation we never zero i2c_defer_count, so
> we can't expect this to work, since we may start drm_dp_i2c_do_msg
> with a i2c_defer_count value different than zero. Also, during i915.ko
> DP compliance we only zero i2c_defer_count at the very beginning of
> each test, not at every aux transaction, and I really think we need a
> solution that is not specific to compliance testing.
To capture the discussion from IRC:

The primary issue previously was the potential for an infinite loop when 
decrementing the retry count. That is clearly addressed by this code, by 
only decrementing the loop while the defer count is below 8. In 
actuality, that needs to be 7, so a followup patch with that change will 
be posted shortly. There are other solutions (Ville has one in his 
reply), but this one works correctly, is minimally invasive and doesn't 
require changes to the loop structure.

The defer counter isn't used anywhere outside of Displayport compliance 
testing. In fact, the counters in the aux struct didn't even exist until 
I put them in there in a previous patch to support this exact test case. 
So there really isn't a non-DP compliance test specific solution to be 
had here. It's also unlikely that this has any significant effect on 
normal operations. In the event that a device misbehaves and begins 
issuing loads of defers, this code would only delay it by at most 7 
retries before the counter exceeded its value.

Since this value is not used outside of compliance testing, a reset 
per-transaction is unnecessary. Additionally, that would break the EDID 
compliance testing code as it would have no way of detecting that the 
read had failed due to continuous defers. As long as the counter is 
reset for each test request (which it is), this code will function 
properly for both real world and compliance operations.

As indicated in the comments, this code exists to ensure compliance with 
test 4.2.2.5 from the Displayport Link CTS Core 1.2 rev1.1. This test 
verifies that the source device is capable of responding to a failure to 
read the EDID when the sink device continuously defers the transaction. 
It ensures that at least 7 I2C defers are received before calling it 
quits, versus simply retrying the transaction 7 times regardless of the 
failure mode.

Since I'm going to post an updated patch anyways, I will likely roll the 
defer count increment into the if-statement to remove one line of code. 
That also requires moving the increment to a pre- versus post- 
condition, as follows:

     ...
     if (++aux->i2c_defer_count < 7)
         ...
     ...

>
>> +                               retry--;
>>                          usleep_range(400, 500);
>>                          continue;
>>
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>


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

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

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

  parent reply	other threads:[~2015-04-07 18:47 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-31 17:14 [intel-gfx][PATCH V4] Displayport compliance testing V4 Todd Previte
2015-03-31 17:14 ` [PATCH 1/9] drm/i915: Add automated testing support for Displayport compliance testing Todd Previte
2015-04-07  0:10   ` Paulo Zanoni
2015-04-07  2:15     ` Todd Previte
2015-04-08 15:35     ` Todd Previte
2015-03-31 17:14 ` [PATCH 2/9] drm/i915: Update intel_dp_check_link_status() " Todd Previte
2015-03-31 17:15 ` [PATCH 3/9] drm/i915: Add a delay in Displayport AUX transactions for " Todd Previte
2015-04-01 18:23   ` Ville Syrjälä
2015-04-01 18:55     ` Todd Previte
2015-04-01 19:22       ` Ville Syrjälä
2015-04-01 19:45         ` Todd Previte
2015-04-06 23:28           ` Paulo Zanoni
2015-04-07  2:07             ` Todd Previte
2015-04-03 16:08   ` [PATCH 03/11] " Todd Previte
2015-04-07  2:09   ` Todd Previte
2015-04-07 13:57     ` Paulo Zanoni
2015-04-09 18:49       ` Todd Previte
2015-03-31 17:15 ` [PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport " Todd Previte
2015-04-08 16:51   ` [Intel-gfx] " Paulo Zanoni
2015-04-08 21:43     ` Todd Previte
2015-04-08 22:37       ` Paulo Zanoni
2015-04-10 14:44         ` Todd Previte
2015-03-31 17:15 ` [PATCH 5/9] drm/i915: Update the EDID automated compliance test function Todd Previte
2015-04-08 17:02   ` Paulo Zanoni
2015-04-09 21:36     ` Todd Previte
2015-03-31 17:15 ` [PATCH 6/9] drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation Todd Previte
2015-04-01 18:00   ` [PATCH 06/11] " Todd Previte
2015-04-08 18:53     ` Paulo Zanoni
2015-04-09 21:35       ` Todd Previte
2015-03-31 17:15 ` [PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling Todd Previte
2015-04-07  0:05   ` Paulo Zanoni
2015-04-07  1:21     ` Todd Previte
2015-04-07  2:11   ` [PATCH 07/11] " Todd Previte
2015-04-07 14:29     ` Paulo Zanoni
2015-04-07 14:47       ` Ville Syrjälä
2015-04-07 18:47       ` Todd Previte [this message]
2015-03-31 17:15 ` [PATCH 8/9] drm/i915: Add debugfs test control files for Displayport compliance testing Todd Previte
2015-04-01 18:12   ` [PATCH 08/11] " Todd Previte
2015-03-31 17:15 ` [PATCH 9/9] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg() Todd Previte
2015-04-01  4:45   ` shuang.he
2015-04-06 21:16   ` [Intel-gfx] " Paulo Zanoni

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=5524263F.2020106@gmail.com \
    --to=tprevite@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@gmail.com \
    /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