summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorMichal Wajdeczko <michal.wajdeczko@intel.com>2026-04-10 13:04:57 +0200
committerMichal Wajdeczko <michal.wajdeczko@intel.com>2026-04-11 17:06:07 +0200
commit4d33314decfeac8b82d771a1bd083a59f4ac6fae (patch)
tree97b3366c8db50a8bdf0bb61b7e4228400bb4e864 /include/linux
parent45334d5c364498629b314391c7d1eac0b64c882f (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')
0 files changed, 0 insertions, 0 deletions