diff options
| author | Michal Wajdeczko <michal.wajdeczko@intel.com> | 2026-04-10 13:04:57 +0200 |
|---|---|---|
| committer | Michal Wajdeczko <michal.wajdeczko@intel.com> | 2026-04-11 17:06:07 +0200 |
| commit | 4d33314decfeac8b82d771a1bd083a59f4ac6fae (patch) | |
| tree | 97b3366c8db50a8bdf0bb61b7e4228400bb4e864 /include/linux/timerqueue_types.h | |
| parent | 45334d5c364498629b314391c7d1eac0b64c882f (diff) | |
drm/xe/guc: Add support for NO_RESPONSE_BUSY in CTB
We only have support for G2H NO_RESPONSE_BUSY messages over MMIO,
but it turned out that GuC also uses that type of messages in CTB.
The following error was recently observed on BMG after adding VGT
policy updates to the GT restart sequence:
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: G2H channel broken on read, type=3, reset required
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: CT dequeue failed: -95
...
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: Timed out wait for G2H, fence 21965, action 5502, done no
[] xe 0000:03:00.0: [drm] PF: Tile0: GT1: Failed to push 1 policy KLV (-ETIME)
[] xe 0000:03:00.0: [drm] Tile0: GT1: { key 0x8004 : no value } # engine_group_config
where type=3 was this unrecognized NO_RESPONSE_BUSY message.
Note that GuC might send the real RESPONSE message right after
the BUSY message, so we must be prepared to update our g2h_fence
data twice before sender actually wakes up and clears the flags.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260410110457.573-1-michal.wajdeczko@intel.com
Diffstat (limited to 'include/linux/timerqueue_types.h')
0 files changed, 0 insertions, 0 deletions
