Claude review: drm/xe/ggtt: hold FORCEWAKE while updating GGTT PTEs on LNL

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/xe/ggtt: hold FORCEWAKE while updating GGTT PTEs on LNL
Author: Nikolay Mikhaylov <sonny@milton.pro>
Patches: 1
Reviewed: 2026-05-25T20:52:12.654181

---

This is a single-patch series that adds FORCEWAKE protection around GGTT PTE writes in the xe driver to prevent hangs on Lunar Lake (LNL) systems. The problem is well-understood: `xe_pm_runtime_get_noresume()` prevents D3 entry but doesn't prevent RC6, and on LNL the GuC autonomously enters RC6 via `GUCRC_FIRMWARE_CONTROL`. When the GT is in RC6, `writeq()` to GSM hangs.

The patch is well-motivated with real user testing backing it. The approach of wrapping PTE write batches in `xe_with_force_wake()` is reasonable and narrowly targeted.

**Concern:** There are additional GGTT PTE write paths in the same file that are **not** wrapped with FORCEWAKE:

1. **`xe_ggtt_map_bo_unlocked()`** (line 735–744) — called from `xe_bo_evict.c` to restore GGTT mappings after suspend. This calls `xe_ggtt_map_bo()` which writes PTEs via `ggtt_set_pte`. This path is not protected.

2. **`xe_ggtt_assign_locked()`** (line 971–987) — SR-IOV PF path that writes PTEs in a loop. Not protected.

3. **`xe_ggtt_node_load()`** (line 1053–1080) — SR-IOV node load path that writes PTEs in a loop. Not protected.

The commit message acknowledges the change is limited to "paths where the hang has been observed," which is a defensible position for a targeted fix. However, `xe_ggtt_map_bo_unlocked()` is called during resume from suspend and seems like it could plausibly hit the same issue on LNL if the GT re-enters RC6 quickly after resume.

---

---
Generated by Claude Code Patch Reviewer