[Intel-gfx] [PATCH 03/17] drm/i915: Add a delay in Displayport AUX transactions for compliance testing

Todd Previte tprevite at gmail.com
Wed Feb 18 08:37:09 PST 2015


On 12/15/2014 10:35 AM, Paulo Zanoni wrote:
> 2014-12-10 21:53 GMT-02:00 Todd Previte<tprevite at gmail.com>:
>> The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
>> specifies that repeated AUX transactions after a failure (no response /
>> invalid response) must have a minimum delay of 400us before the resend can
>> occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.
>>
>> V2:
>> - Changed udelay() to usleep_range()
>>
>> Signed-off-by: Todd Previte<tprevite at gmail.com>
>> ---
>>   drivers/gpu/drm/i915/intel_dp.c | 7 ++++++-
>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 1b452cc..b6f5a72 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -876,9 +876,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>>                                     DP_AUX_CH_CTL_TIME_OUT_ERROR |
>>                                     DP_AUX_CH_CTL_RECEIVE_ERROR);
>>
>> +                       /* DP compliance requires 400us delay for errors
>> +                          and timeouts (DP CTS 1.2 Core Rev 1.1, 4.2.1.1
>> +                          & 4.2.1.2) */
>>                          if (status & (DP_AUX_CH_CTL_TIME_OUT_ERROR |
>> -                                     DP_AUX_CH_CTL_RECEIVE_ERROR))
>> +                                     DP_AUX_CH_CTL_RECEIVE_ERROR)) {
>> +                               usleep_range(400, 500);
> One thing to notice is that if we get a TIME_OUT_ERROR I guess it
> means we already waited our standard timeout (which is either 400, 600
> or 1600, depending on the platform), so shouldn't we just do the
> usleep() after the RECEIVE_ERROR error?
Capture of IRC discussion:

It seems reasonable to just continue to the next iteration if the HW has 
already hit a timeout condition. Testing has determined that it is not 
necessary to handle the timeout case, since the HW has already waited 
the required amount of time. That case has been removed and the comment 
has been updated for V3.

>>                                  continue;
>> +                       }
>>                          if (status & DP_AUX_CH_CTL_DONE)
>>                                  break;
>>                  }
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



More information about the Intel-gfx mailing list