Claude review: drm/amd/display: Change dither policy for 10 bpc output back to dithering

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

Patch Review

**Correctness:** The change at `dc_resource.c:5057-5058` from `DITHER_OPTION_TRUN10` to `DITHER_OPTION_SPATIAL10` is correct. Looking at the downstream handling:

- `DITHER_OPTION_SPATIAL10` is handled at lines 5125-5133, which sets `SPATIAL_DITHER_ENABLED = 1`, `SPATIAL_DITHER_DEPTH = 2`, along with `HIGHPASS_RANDOM` and conditional `RGB_RANDOM`. This is the proper spatial dithering path.
- The old `DITHER_OPTION_TRUN10` at lines 5076-5086 only set truncation with `TRUNCATE_MODE = 1` (rounding), losing the precision benefit of spatial dithering.
- The pattern is now consistent with `COLOR_DEPTH_666 → DITHER_OPTION_SPATIAL6` and `COLOR_DEPTH_888 → DITHER_OPTION_SPATIAL8`.

**Commit message quality:** Excellent. The author provides thorough technical justification for the revert, explains the real-world impact (scientific applications, fp16/rgba16 framebuffers, the 8 bpc vs 10 bpc absurdity), names specific software that benefits (Mesa 25.3, GNOME 50 mutter), and documents actual hardware testing (Polaris DCE 11.2 and Raven Ridge DCN 1.0 with photometer measurements).

**Minor observations:**
- The `Fixes:` tag and `Cc: stable` are appropriate since this is restoring a regression in precision for users of > 10 bpc pipelines.
- The only concern would be whether there exists some hardware where spatial dithering to 10 bpc causes visual artifacts — but the author explicitly tested on two different generations (Polaris and Raven Ridge) with no issues, and the original commit that introduced truncation did not cite any such hardware problems either.

**No issues found.** This is a clean, well-justified fix.

---
Generated by Claude Code Patch Reviewer