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/msm/dsi: Add support for RGB101010 pixel format Date: Sun, 22 Mar 2026 03:12:29 +1000 Message-ID: In-Reply-To: <20260321-dsi-rgb101010-support-v4-5-eb28ecebbfe8@pm.me> References: <20260321-dsi-rgb101010-support-v4-0-eb28ecebbfe8@pm.me> <20260321-dsi-rgb101010-support-v4-5-eb28ecebbfe8@pm.me> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The format mappings are added to both vid and cmd mode: ```c case MIPI_DSI_FMT_RGB101010: return VID_DST_FORMAT_RGB101010; ... case MIPI_DSI_FMT_RGB101010: return CMD_DST_FORMAT_RGB101010; ``` The VID_CFG0 DST_FORMAT bitfield is extended from 2 bits to 3 bits: ```xml ``` This is necessary since value 4 (`VID_DST_FORMAT_RGB101010`) requires 3 bits. The comment documenting the hardware version dependency is helpful. The version guard in `dsi_host_attach`: ```c if (dsi->format == MIPI_DSI_FMT_RGB101010 && !msm_dsi_host_version_geq(msm_host, MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_1_0)) { ``` This correctly gates RGB101010 to v2.1.0+ controllers. Writing bit 6 of DST_FORMAT on older hardware (where that bit belongs to a different field or is reserved) could cause undefined behavior, so the guard is important. **One minor concern:** The 3-bit DST_FORMAT bitfield is unconditionally defined in the XML register description. On pre-v2.1.0 hardware, bit 6 may overlap with another field. The XML comment notes this, but the generated header will always use the 3-bit definition regardless of hardware version. Since the format guard in `dsi_host_attach` prevents actually writing value 4 on old hardware, this is safe in practice, but it does mean the register description is technically inaccurate for older hardware revisions. **No blocking issues.** --- Generated by Claude Code Patch Reviewer