diff mbox

drm/dp: retry AUX transactions 32 times (v1.1)

Message ID 87r3wo3g8s.fsf@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jani Nikula Nov. 27, 2014, 1:49 p.m. UTC
On Wed, 26 Nov 2014, Dave Airlie <airlied@gmail.com> wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
>
> This fixes one Dell 4k monitor and one of the
> MST hubs.
>
> v1.1: fixup comment (Tom).

Missed this version, see my reply to v1:
http://mid.gmane.org/87k32iqppg.fsf@intel.com

Also, what if you avoid sink dpms off with:


Does it make a difference?

BR,
Jani.


>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 959e207..79968e3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -186,10 +186,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
>  
>  	/*
>  	 * The specification doesn't give any recommendation on how often to
> -	 * retry native transactions, so retry 7 times like for I2C-over-AUX
> -	 * transactions.
> +	 * retry native transactions. We used to retry 7 times like for
> +	 * aux i2c transactions but real world devices this wasn't
> +	 * sufficient, bump to 32 which makes Dell 4k monitors happier.
>  	 */
> -	for (retry = 0; retry < 7; retry++) {
> +	for (retry = 0; retry < 32; retry++) {
>  
>  		mutex_lock(&aux->hw_mutex);
>  		err = aux->transfer(aux, &msg);
> -- 
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Comments

Dave Airlie Dec. 8, 2014, 11:53 p.m. UTC | #1
> Missed this version, see my reply to v1:
> http://mid.gmane.org/87k32iqppg.fsf@intel.com
>
> Also, what if you avoid sink dpms off with:
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 70bb8d0b9695..768b1bfaea78 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1932,7 +1932,7 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>
>         if (mode != DRM_MODE_DPMS_ON) {
>                 ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> -                                        DP_SET_POWER_D3);
> +                                        DP_SET_POWER_D0);
>         } else {
>                 /*
>                  * When turning on, we need to retry for 1ms to give the sink
>
> Does it make a difference?

Meant to reply, but the sink is definitely out of dpms when hit this,

I've already done a fair few dpcd transactions, and asked it to link train,
It is mostly link training the downstream at that point that I think is making
it defer.

Dave.
Jani Nikula Dec. 9, 2014, 8:24 a.m. UTC | #2
On Tue, 09 Dec 2014, Dave Airlie <airlied@gmail.com> wrote:
>> Missed this version, see my reply to v1:
>> http://mid.gmane.org/87k32iqppg.fsf@intel.com
>>
>> Also, what if you avoid sink dpms off with:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 70bb8d0b9695..768b1bfaea78 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1932,7 +1932,7 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>>
>>         if (mode != DRM_MODE_DPMS_ON) {
>>                 ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
>> -                                        DP_SET_POWER_D3);
>> +                                        DP_SET_POWER_D0);
>>         } else {
>>                 /*
>>                  * When turning on, we need to retry for 1ms to give the sink
>>
>> Does it make a difference?
>
> Meant to reply, but the sink is definitely out of dpms when hit this,
>
> I've already done a fair few dpcd transactions, and asked it to link train,
> It is mostly link training the downstream at that point that I think is making
> it defer.

Okay, ack on the patch then. I wish we had something better to base the
limit on, but if this makes it work, so be it.

BR,
Jani.


>
> Dave.
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 70bb8d0b9695..768b1bfaea78 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1932,7 +1932,7 @@  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 
 	if (mode != DRM_MODE_DPMS_ON) {
 		ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
-					 DP_SET_POWER_D3);
+					 DP_SET_POWER_D0);
 	} else {
 		/*
 		 * When turning on, we need to retry for 1ms to give the sink