On Sat, 21 Nov 2015, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote:
> The goal here is to offload aux retries handling from the
> drivers to drm.
>
> However there are 2 differents cases for retry:
> 1. Immediately retry - Hardware already took care of needed timeouts
> before answering that a retry is possible.
> 2. Busy - Wait some time and retry.
>
> This driver introduce the support for EAGAIN that can handle the
> first case and a following patch will introduce EBUSY waits,
> after all drivers counting on immediately retries are changed.
>
> Cc: Dave Airlie <airlied@xxxxxxxxxx>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> ---
> drivers/gpu/drm/drm_dp_helper.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9535c5b..ee7c955 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -198,6 +198,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> err = aux->transfer(aux, &msg);
> mutex_unlock(&aux->hw_mutex);
> if (err < 0) {
> + /* Immediately retry */
> + if (err == -EAGAIN)
> + continue;
How about the ->transfer call in drm_dp_i2c_do_msg? If we leave that for
the i2c layer (which does do retries on -EAGAIN, but also handles
timeouts for repeated -EAGAINs) it deserves a comment in in
drm_dp_i2c_do_msg.
BR,
Jani.
> +
> + /* FIXME: On BUSY we could wait before retrying */
> if (err == -EBUSY)
> continue;
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
