[Intel-gfx] [PATCH 2/2] drm/i915: Swap ret and status returned from skl_pcode_request

Govindapillai, Vinod vinod.govindapillai at intel.com
Fri Apr 8 17:41:40 UTC 2022


On Fri, 2022-04-08 at 15:52 +0300, Stanislav Lisovskiy wrote:
> If ret isn't zero, it is almost for sure ETIMEDOUT, because
> we use it in wait_for macro which does continuous retries
> until timeout is reached. If we still ran out of time and
> retries, we most likely would be interested in getting status,
> to understand what was the actual error propagated from PCode,
> rather than to find out that we had a time out, which is anyway
> quite obvious, if the function fails.
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c
> index fb6c43e8a02f..a68eaf510784 100644
> --- a/drivers/gpu/drm/i915/intel_pcode.c
> +++ b/drivers/gpu/drm/i915/intel_pcode.c
> @@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request,
>  
>  out:
>  	mutex_unlock(&i915->sb_lock);
> -	return ret ? ret : status;
> +	return ret ? status : ret;

Isnt this equivalent to "return status" 
When we were discussing this, I felt this is good. 
But on further check with the functions gen7_check_mailbox_status(), is there a possibility that
status = 0 but "request & reply_mask) != reply" for the "default" case handling?

In that cast _wait_for() will be timedout with ret = ETimedOut but "status" = 0

Is that real scenario? 


>  #undef COND
>  }
>  


More information about the Intel-gfx mailing list