[PATCH] drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh

[PATCH] drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh

[Belousov Maksim]

The ili9486 driver uses DRM_SIMPLE_MODE() which sets the pixel
clock to 1 kHz. Since htotal==hdisplay and vtotal==vdisplay,
the calculated vrefresh is:

    1000 / (480 * 320) = 0.006 Hz

This breaks Wayland compositors in two ways. Compositors that
use the mode's refresh rate to schedule their repaint loop
(such as Weston) compute a repaint delay of over a second,
triggering abnormal delay warnings and degrading rendering.
Compositors that are page-flip driven (such as wlroots-based
compositors) are unaffected at the compositor level, but still
report the near-zero rate to clients via wl_output.mode. This
causes toolkits such as GTK4 to not schedule redraws, so
applications render their initial frame but never visually
update in response to input.

Replace DRM_SIMPLE_MODE() with DRM_MODE_INIT(30, ...) which
properly calculates the pixel clock for a 30 Hz target refresh
rate. 30 Hz is a conservative default achievable on most SPI
setups. The actual frame rate remains bounded by SPI bus
throughput; the mode's vrefresh only affects how compositors
and clients schedule rendering.

Note: other tiny DRM drivers (hx8357d, ili9163, ili9225,
ili9341, mi0283qt, repaper, sharp-memory) have the same issue
and would benefit from the same change.

Tested on Raspberry Pi 4 with ILI9486-based MHS-3.5" SPI LCD
(480x320). With Weston, the compositor logs "computed repaint
delay is abnormal" warnings. With sway (wlroots), GTK4 clients
fail to visually update. Both issues are resolved by this
patch.

Signed-off-by: Belousov Maksim <mail@singulared.space>
---
 drivers/gpu/drm/tiny/ili9486.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1e411a0f4..83eda43bd 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -165,7 +165,7 @@ static const struct drm_simple_display_pipe_funcs waveshare_pipe_funcs = {
 };
 
 static const struct drm_display_mode waveshare_mode = {
-	DRM_SIMPLE_MODE(480, 320, 73, 49),
+	DRM_MODE_INIT(30, 480, 320, 73, 49),
 };
 
 DEFINE_DRM_GEM_DMA_FOPS(ili9486_fops);
-- 
2.51.0

Claude review: drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh

[Claude Code Review Bot]

Overall Series Review

Subject: drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh
Author: Belousov Maksim <mail@singulared.space>
Patches: 1
Reviewed: 2026-02-24T10:01:43.534737

---

This is a single-patch series that fixes the display mode definition in the ili9486 tiny DRM driver. The driver currently uses `DRM_SIMPLE_MODE()` which sets a dummy pixel clock of 1 kHz, resulting in a calculated vrefresh of approximately 0.006 Hz. The patch replaces it with `DRM_MODE_INIT(30, ...)` which computes a pixel clock that yields a 30 Hz vrefresh value.

The commit message is well-written and provides concrete evidence of the problem: Weston logs abnormal repaint delay warnings, and GTK4 clients under wlroots-based compositors fail to visually update because they use the reported refresh rate for scheduling. The fix is minimal and appropriate — a single macro substitution with no behavioral side effects beyond the mode metadata. The pixel clock calculation (`480 * 320 * 30 / 1000 = 4608 kHz`) is correct and produces the intended 30 Hz vrefresh. No issues found.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh

[Claude Code Review Bot]

Patch Review

> -	DRM_SIMPLE_MODE(480, 320, 73, 49),
> +	DRM_MODE_INIT(30, 480, 320, 73, 49),

The change is correct. Both macros expand through `__DRM_MODE_INIT`, which sets `htotal == hdisplay` and `vtotal == vdisplay` (no blanking intervals), appropriate for an SPI-driven panel with no real sync timing. The only difference is the `.clock` field:

- `DRM_SIMPLE_MODE`: clock = 1 kHz → vrefresh = 1000 / (480 × 320) ≈ 0.006 Hz
- `DRM_MODE_INIT(30, ...)`: clock = 480 × 320 × 30 / 1000 = 4608 kHz → vrefresh = 30 Hz

The multiplication `480 * 320 * 30 = 4,608,000` fits comfortably in an `int` with no overflow risk. The 30 Hz target is reasonable for an SPI display — the actual frame rate will still be limited by bus throughput as noted in the commit message.

The physical dimensions (73 mm × 49 mm) are unchanged, and `DRM_MODE_INIT` is already used in-tree by `appletbdrm.c`, so this is an established pattern.

No issues found. The patch is a clean, minimal fix with a thorough commit message.

---
Generated by Claude Code Patch Reviewer