Claude review: drm/vblank: Add vblank timer

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

Patch Review

Cherry-pick of upstream `74afeb8128502a529041a2566febd26053a7be11`.

The core of the series. Introduces `struct drm_vblank_crtc_timer` and three new exported functions: `drm_crtc_vblank_start_timer()`, `drm_crtc_vblank_cancel_timer()`, and `drm_crtc_vblank_get_vblank_timeout()`. Also creates `drm_vblank_helper.c` with wrapper callbacks for `drm_crtc_funcs`.

The deadlock avoidance is the key design choice — in `drm_crtc_vblank_cancel_timer()`:
```c
spin_lock_irqsave(&vtimer->interval_lock, flags);
vtimer->interval = 0;
spin_unlock_irqrestore(&vtimer->interval_lock, flags);
hrtimer_try_to_cancel(&vtimer->timer);
```
Instead of `hrtimer_cancel()` (which waits and can deadlock), this signals the timer to self-terminate by zeroing the interval and uses `hrtimer_try_to_cancel()`. The timer function checks:
```c
if (!interval)
    return HRTIMER_NORESTART;
```
This is a correct pattern to avoid the ABBA deadlock between `vblank_time_lock` and `softirq_expiry_lock`.

The comment in `drm_crtc_vblank_cancel_timer()` has a typo: `vblank_time_lime_lock` instead of `vblank_time_lock`. This exists in the upstream commit too, so it's not introduced by the backport.

One pre-existing note on `drm_crtc_vblank_start_timer()`: the busy-wait `while (hrtimer_active(...)) hrtimer_try_to_cancel(...)` loop on the non-first-invocation path could theoretically spin for a long time if the timer function keeps restarting, but in practice the interval-zeroing from cancel ensures this converges. This is unchanged from upstream.

**No issues with the backport itself.**

---
Generated by Claude Code Patch Reviewer