Claude review: drm/amd/display: Implement deferred vblanks on IPS platforms

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

Patch Review

This is the driver-side implementation. The pre/post callbacks acquire/release `dc_lock` to bracket HW access. The design is sound in principle.

**Issue 1: `crtc->state` access from worker context**

In `amdgpu_dm_crtc_post_enable_vblank()` and `amdgpu_dm_crtc_post_disable_vblank()`:

```c
struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
```

These run from the deferred workqueue, meaning there's a window between when the work was queued (from `drm_vblank_get()`) and when it executes. During that window, an atomic commit could swap `crtc->state`. Accessing `crtc->state` without holding `drm_modeset_lock` from a worker is unsafe. The stream pointer could become stale or freed.

Consider either:
- Capturing the stream reference at queue time and passing it through to the worker, or
- Ensuring `dc_lock` serialization is sufficient to prevent state changes (it might be, since commits also take `dc_lock`, but this is fragile and should be documented)

**Issue 2: dc_lock held across drm_vblank_enable/disable internals**

`pre_enable_vblank` takes `dc_lock` and `post_enable_vblank` releases it. This means `dc_lock` is held while the DRM core calls `__enable_vblank` → `enable_vblank` callback → `amdgpu_dm_crtc_deferred_enable_vblank()`. That callback also does `amdgpu_dm_crtc_set_vblank()` which itself touches DC state. Since `dc_lock` is already held, this requires that all the code in the `set_vblank` path is safe for recursive `dc_lock` holding (mutex is not recursive by default). Verify that `dc_lock` isn't taken again inside `set_vblank` → interrupt enable path, or this will deadlock.

**Issue 3: Missing `crtc->enabled` check in deferred enable**

As noted in patch 3 review, `amdgpu_dm_crtc_deferred_enable_vblank()` doesn't check `crtc->enabled` before calling `set_vblank`. The `post_enable_vblank` callback does check `crtc->enabled` and bails early, but `active_vblank_irq_count` has already been incremented by that point.

**Issue 4: Duplicate vtable**

`amdgpu_dm_crtc_deferred_vblank_funcs` duplicates the entire `amdgpu_dm_crtc_funcs` structure with only 6 fields differing (enable/disable_vblank + 4 pre/post callbacks). If future changes are made to `amdgpu_dm_crtc_funcs`, the deferred variant must be kept in sync manually. Consider documenting this coupling prominently, or using a helper to populate shared fields.

---
Generated by Claude Code Patch Reviewer