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: Implement "color format" DRM property Date: Sun, 12 Apr 2026 11:01:43 +1000 Message-ID: In-Reply-To: <20260409-color-format-v12-17-ce84e1817a27@collabora.com> References: <20260409-color-format-v12-0-ce84e1817a27@collabora.com> <20260409-color-format-v12-17-ce84e1817a27@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Substantial patch. Adds `dw_hdmi_qp_rockchip_bus_fmt_to_reg()` for GRF register values, and `dw_hdmi_qp_rockchip_get_vop_format()` to query bridge state for the format to feed the VOP. **Notes**: 1. The unified `RK_COLOR_FMT_*` defines replacing per-SoC defines is a good cleanup -- both RK3576 and RK3588 use the same values. 2. `dw_hdmi_qp_rockchip_get_vop_format()` uses `__free(drm_bridge_put)` for cleanup. The RAII pattern here is correct. 3. The GRF write uses `likely(color >= 0)`: ```c if (likely(color >= 0)) val |= FIELD_PREP_WM16(RK3576_COLOR_FORMAT_MASK, color); ``` The `likely()` annotation is appropriate since the bus format was already validated in atomic_check. 4. `MEDIA_BUS_FMT_UYVY10_1X20` is handled in the switch but `MEDIA_BUS_FMT_UYVY8_1X16` is the only 8-bit YUV422 variant. Missing `MEDIA_BUS_FMT_YUYV8_1X16` and other orderings? Probably fine since the bridge helper only emits UYVY variants. R-b from Cristian Ciocaltea. **Verdict**: Good. --- --- Generated by Claude Code Patch Reviewer