drm/xe/guc: Resend potentially lost H2G MMIO request

There could be a scenario where the VF driver is resuming faster
than the driver PF is able to complete the VF FLR sequence which
includes reset of the VF scratch registers.  This may result in
deletion of the ongoing HXG message (it could be either a host
request or a GuC response).

When we detect that HXG message was likey lost (scratch register
with HXG header was zeroed) try to send this request once more
before giving up.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Link: https://lore.kernel.org/r/20250528090021.329-1-michal.wajdeczko@intel.com
This commit is contained in:
Michal Wajdeczko
2025-05-28 11:00:21 +02:00
parent eae7844758
commit d65650a9d1

View File

@@ -1289,6 +1289,7 @@ int xe_guc_mmio_send_recv(struct xe_guc *guc, const u32 *request,
struct xe_reg reply_reg = xe_gt_is_media_type(gt) ?
MED_VF_SW_FLAG(0) : VF_SW_FLAG(0);
const u32 LAST_INDEX = VF_SW_FLAG_COUNT - 1;
bool lost = false;
int ret;
int i;
@@ -1322,6 +1323,12 @@ retry:
FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_GUC),
50000, &reply, false);
if (ret) {
/* scratch registers might be cleared during FLR, try once more */
if (!reply && !lost) {
xe_gt_dbg(gt, "GuC mmio request %#x: lost, trying again\n", request[0]);
lost = true;
goto retry;
}
timeout:
xe_gt_err(gt, "GuC mmio request %#x: no reply %#x\n",
request[0], reply);