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: bridge: ti-sn65dsi83: Remove NO_HFP and NO_HBP mode flags for LVDS stability Date: Thu, 28 May 2026 12:36:19 +1000 Message-ID: In-Reply-To: <20260527085736.920390-2-tessolveupstream@gmail.com> References: <20260527085736.920390-1-tessolveupstream@gmail.com> <20260527085736.920390-2-tessolveupstream@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Verdict: Good patch, should be accepted.** The change removes `MIPI_DSI_MODE_VIDEO_NO_HFP` and `MIPI_DSI_MODE_VIDEO_NO= _HBP` from the DSI mode flags: ```c dsi->mode_flags =3D MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | - MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET; ``` This is well-justified. The `NO_HFP`/`NO_HBP` flags tell the DSI host it ca= n skip sending horizontal front/back porch periods, but the driver programs= these exact values into the bridge chip's registers at lines 672=E2=80=936= 77: ```c regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH, (mode->htotal - mode->hsync_end) / dual_factor); regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH, (mode->hsync_start - mode->hdisplay) / dual_factor); ``` The bridge chip clearly needs these blanking periods to reconstruct valid L= VDS timings. Suppressing them on the DSI link while expecting the bridge to= use them is inconsistent. The datasheet reference strengthens the argument= . Note that `MIPI_DSI_MODE_VIDEO_NO_HSA` is intentionally retained =E2=80= =94 this is reasonable since the bridge has its own hsync-width register (`= REG_VID_CHA_HSYNC_PULSE_WIDTH`) and can reconstruct HSA from the programmed= value. No issues with the code change itself. Two independent Tested-by tags add c= onfidence. --- Generated by Claude Code Patch Reviewer