On Sat, 21 Nov 2015, Rodrigo Vivi 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
> Signed-off-by: Rodrigo Vivi
> ---
> 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;
> }
--
Jani Nikula, Intel Open Source Technology Center
