[Intel-xe] [PATCH] drm/xe/guc: Return the lower part of blocking H2G message

[Michal Wajdeczko]

On 24.10.2023 00:11, Matthew Brost wrote:
> The upper layers may need this data, an example of this is allocating
> DIST doorbell.
> 
> v2 (Michal): Drop change of checking the return value.
> 
> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
> ---
>  drivers/gpu/drm/xe/xe_guc_ct.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> index 8b686c8b3339..092a9563f80a 100644
> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> @@ -26,6 +26,7 @@
>  struct g2h_fence {
>  	u32 *response_buffer;
>  	u32 seqno;
> +	u32 status;

this name might be misleading, as in response message we don't expect
'status', but rather generic 'data' from GUC_HXG_RESPONSE_MSG_0_DATA0

>  	u16 response_len;
>  	u16 error;
>  	u16 hint;
> @@ -749,7 +750,7 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
>  		ret = -EIO;
>  	}
>  
> -	return ret > 0 ? 0 : ret;
> +	return ret > 0 ? g2h_fence.status : ret;

while this helps for cases when all returned data is in data0, and
likely caller didn't even provide buffer for the response, but it still
wont solve the problems with flexible size G2H responses, as caller, who
had provided buffer for the response, still doesn't know how many dwords
were copied into it

can we have similar logic as in i915 where we return response_len if
there was buffer provided, and response_data if not ?

>  }
>  
>  int xe_guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
> @@ -815,6 +816,9 @@ static int parse_g2h_response(struct xe_guc_ct *ct, u32 *msg, u32 len)
>  		g2h_fence->response_len = response_len;
>  		memcpy(g2h_fence->response_buffer, msg + GUC_CTB_MSG_MIN_LEN,
>  		       response_len * sizeof(u32));
> +	} else {
> +		g2h_fence->status =
> +			FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, msg[1]);
>  	}
>  
>  	g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);