Claude review: drm/amd/display: Refactor amdgpu_dm_crtc_set_vblank

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

Patch Review

This is a reasonable cleanup separating the vblank workqueue management from the actual interrupt enable/disable logic.

**Observation:** The refactored `amdgpu_dm_crtc_set_vblank()` now uses `enable && crtc->enabled` as its guard:

```c
if (enable && crtc->enabled) {
    // do enable work
}
```

When `enable=true` but `crtc->enabled=false`, this silently returns 0 (success) without actually enabling anything. The caller `amdgpu_dm_crtc_enable_vblank()` checks `!crtc->enabled` and rejects early, so for the non-deferred path this is fine. But in patch 4, `amdgpu_dm_crtc_deferred_enable_vblank()` does **not** check `crtc->enabled` and calls `set_vblank(crtc, true)` directly. If the CRTC is disabled, `set_vblank` returns 0, and `active_vblank_irq_count` gets incremented without actually enabling the interrupt. The count will be balanced on disable, but the vblank core now believes the interrupt was successfully enabled when it wasn't.

**Also:** `amdgpu_dm_crtc_queue_vblank_work()` still uses `GFP_ATOMIC` for the allocation. Since the callers (`enable_vblank`/`disable_vblank` callbacks) can be called from atomic context in the non-deferred path this is needed. But for future clarity, a comment would help.

---
Generated by Claude Code Patch Reviewer