On Sat, 21 Nov 2015, Rodrigo Vivi rodrigo.vivi@intel.com wrote:
DP Specs isn't really clear about the amount of retries, but for cases it mentions retries it also mention times that vary from 300us to 1ms.
For many cases hardware can handled the timeouts before retry is possible and allowed, but for many other cases it is better to wait and give time so the aux channels can recover.
For instance one general case there is when downstream device is waking up from sleep states generating HPD so it might take up to 1ms before getting responsive.
I believe with this msleep we could minimize the 32 times retries and still let Dell monitors happy, but I don't have this monitor to test here so let's just add the sleep for now and still retry 32 times.
Cc: Dave Airlie airlied@redhat.com Signed-off-by: Rodrigo Vivi rodrigo.vivi@intel.com
drivers/gpu/drm/drm_dp_helper.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index ee7c955..1d6016d 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -202,9 +202,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, if (err == -EAGAIN) continue;
/* FIXME: On BUSY we could wait before retrying */if (err == -EBUSY)
/* Give a time for aux channels to recover */if (err == -EBUSY) {msleep(1);
usleep_range please; msleep(1) may take *much* longer than 1 ms, and that could throw us off with our retry logic.
BR, Jani.
continue;
} return err;}