drm/dp: retry AUX transactions 32 times (v1.1)
Subsystems (3)
Dave Airlie
maintainerPATCH 1/1 drm/dp: retry AUX transactions 32 times (v1.1)
From: Dave Airlie <[email protected]>
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).
--- drivers/gpu/drm/drm_dp_helper.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_dp_helper.c +4 -3
@@ -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);
Signature · 6 lines
2.1.0 _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
-------------------------------------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 [email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 7 lines · Dave Airlie
From: Dave Airlie <[email protected]>
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.
Quoted 6 lines
This fixes one Dell 4k monitor and one of the MST hubs.
v1.1: fixup comment (Tom).
Signed-off-by Dave Airlie <[email protected]>
Quoted 26 lines
--- drivers/gpu/drm/drm_dp_helper.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)drivers/gpu/drm/drm_dp_helper.c +4
-4@@ -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
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Jani Nikula
maintainerQuoted 11 lines · Dave Airlie
From: Dave Airlie <[email protected]>
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/[email protected]
Also, what if you avoid sink dpms off with:
drivers/gpu/drm/i915/intel_dp.c +1 -1
@@ -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.
Quoted 32 lines
Signed-off-by Dave Airlie <[email protected]>--- drivers/gpu/drm/drm_dp_helper.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)drivers/gpu/drm/drm_dp_helper.c +4
-3@@ -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);Signature · 6 lines
2.1.0 _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel
Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Dave Airlie
maintainerQuoted 19 lines
Missed this version, see my reply to v1:
http://mid.gmane.org/[email protected]Also, what if you avoid sink dpms off with:
drivers/gpu/drm/i915/intel_dp.c +1
-1@@ -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
Quoted 1 line
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Jani Nikula
maintainerQuoted 19 lines · Dave Airlie
Quoted 19 lines
Missed this version, see my reply to v1:
http://mid.gmane.org/[email protected]Also, what if you avoid sink dpms off with:
drivers/gpu/drm/i915/intel_dp.c +1
-1@@ -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
Quoted 7 lines
Quoted 1 line
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.
Quoted 2 lines
Dave.
Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel