From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/rockchip: dw_hdmi_qp: Add support for HDMI overscan compensation Date: Thu, 04 Jun 2026 12:35:00 +1000 Message-ID: In-Reply-To: <20260602-hdmi-overscan-v1-0-31f71b817c80@flipper.net> References: <20260602-hdmi-overscan-v1-0-31f71b817c80@flipper.net> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: drm/rockchip: dw_hdmi_qp: Add support for HDMI overscan compensation Author: Alexey Charkov Patches: 6 Reviewed: 2026-06-04T12:35:00.723614 --- This is a 2-patch series adding HDMI overscan compensation to the Rockchip dw_hdmi_qp driver. The approach is: (1) plumb pixel margins through `rockchip_crtc_state` so the VOP2 post-compositor scaler can use them instead of hard-coded 100% values, and (2) expose the standard DRM "overscan" TV property on the HDMI connector and convert the single percentage into per-side pixel margins in `atomic_check`. The overall approach is reasonable and the code is small. There are several issues worth addressing: **Major concern:** The use of `drm_mode_create_tv_properties_legacy()` is explicitly deprecated. The docstring in the kernel says *"New drivers must use drm_mode_create_tv_properties() instead."* This driver doesn't need analog TV mode selection, so calling the legacy function just to get the overscan property creates a bunch of unnecessary and misleading properties (subconnector, brightness, contrast, flicker reduction, saturation, hue, and the legacy mode selector). Only the overscan property is wanted. **Moderate concern:** The early-return logic in `atomic_check` has a subtle interaction with margin changes. If the user changes the overscan percentage but the TMDS rate and BPC stay the same, the margins are computed and written to `s->tv_margins`, but `atomic_check` returns 0 without setting `s->output_mode`, `s->output_type`, or `s->output_bpc`. This works because those fields are preserved across state duplicates, but it means the CRTC state is modified without the function explicitly signaling that a modeset-level change occurred. The margins should probably also trigger a mode change to ensure the CRTC re-programs the post-scaler, though in practice `vop2_post_config` may be called on every commit regardless. --- Generated by Claude Code Patch Reviewer