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);
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
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
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 sinkDoes 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.
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 sinkDoes 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.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Dave Airlie -
Jani Nikula