Re: [PATCH v3 36/36] drm/xe/guc: Increase wait timeout to 2sec after BUSY reply from GuC

[Matthew Brost <matthew.brost@intel.com>]

On Tue, Sep 30, 2025 at 03:38:43PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 9/30/2025 2:39 PM, Matthew Brost wrote:
> > On Mon, Sep 29, 2025 at 08:47:33PM +0530, K V P, Satyanarayana wrote:
> >>
> >>
> >> On 29-09-2025 08:25, Matthew Brost wrote:
> >>> From: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> >>>
> >>> Some VF2GUC actions may take longer to process. Increase default timeout
> >>> after received BUSY indication to 2sec to cover all worst case scenarios.
> >>>
> >>> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>> ---
> >>>   drivers/gpu/drm/xe/xe_guc.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> >>> index c016a11b6ab1..f0de1fa61898 100644
> >>> --- a/drivers/gpu/drm/xe/xe_guc.c
> >>> +++ b/drivers/gpu/drm/xe/xe_guc.c
> >>> @@ -1439,7 +1439,7 @@ int xe_guc_mmio_send_recv(struct xe_guc *guc, const u32 *request,
> >>>   		BUILD_BUG_ON((GUC_HXG_TYPE_RESPONSE_SUCCESS ^ GUC_HXG_TYPE_RESPONSE_FAILURE) != 1);
> >>>   		ret = xe_mmio_wait32(mmio, reply_reg, resp_mask, resp_mask,
> >>> -				     1000000, &header, false);
> >>> +				     2000000, &header, false);
> >>>   		if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
> >>>   			     GUC_HXG_ORIGIN_GUC))
> >>
> >> LGTM.
> >> Acked-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> > 
> > This is your patch, so can't ack by but anyways:
> > 
> > Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> 
> but shouldn't we wait until your previous concern [1] is addressed ?
> 

Nah. That comment is actually invalid too. I misread the code - I didn't
relize this was in GUC_HXG_TYPE_NO_RESPONSE_BUSY path. I think this can
as is fine. We have relatively large waits on the GuC all over the
driver because in practice timeouts shouldn't happen unless the GuC has
died. If anything we should make this timeout bigger here.

Matt

> [1] https://patchwork.freedesktop.org/patch/675316/?series=154682&rev=1#comment_1240144
>