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

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

[Dave Airlie]

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

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

Re: [PATCH] drm/dp: retry AUX transactions 32 times (v1.1)

[shuang.he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
PNV                                  366/366              366/366
ILK                 -5              371/371              366/371
SNB                                  450/450              450/450
IVB                 -1              498/498              497/498
BYT                                  289/289              289/289
HSW                 -1              564/564              563/564
BDW                                  417/417              417/417
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
 ILK  igt_gem_reset_stats_close-pending-fork-render      TIMEOUT(23, M37M26)PASS(1, M26)      TIMEOUT(1, M26)
 ILK  igt_kms_3d      DMESG_WARN(2, M26)PASS(6, M37M26)      DMESG_WARN(1, M26)
 ILK  igt_kms_flip_flip-vs-dpms-off-vs-modeset      DMESG_WARN(2, M26)PASS(3, M37M26)      DMESG_WARN(1, M26)
 ILK  igt_kms_flip_vblank-vs-hang      TIMEOUT(22, M37M26)PASS(1, M26)      TIMEOUT(1, M26)
*ILK  igt_kms_flip_wf_vblank-ts-check      PASS(3, M37M26)      DMESG_WARN(1, M26)
*IVB  igt_kms_cursor_crc_cursor-128x128-random      DMESG_WARN(1, M21)PASS(1, M21)      FAIL(1, M21)
*HSW  igt_kms_fence_pin_leak      PASS(6, M20M19)      DMESG_WARN(1, M20)
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: retry AUX transactions 32 times (v1.1)

[Alex Deucher]

On Tue, Nov 25, 2014 at 10:25 PM, 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).
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>

Acked-by: Alex Deucher <alexander.deucher@amd.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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: retry AUX transactions 32 times (v1.1)

[Jani Nikula]

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:

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?

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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: retry AUX transactions 32 times (v1.1)

[Dave Airlie]

> 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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: retry AUX transactions 32 times (v1.1)

[Jani Nikula]

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.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel