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/tidss: Add mechanism to detect DPI output Date: Thu, 04 Jun 2026 16:54:12 +1000 Message-ID: In-Reply-To: <20260529-beagley-ai-display-v3-8-7fefdc5d1adf@ideasonboard.com> References: <20260529-beagley-ai-display-v3-0-7fefdc5d1adf@ideasonboard.com> <20260529-beagley-ai-display-v3-8-7fefdc5d1adf@ideasonboard.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 This patch plumbs `dpi_output` through from modeset init to the CRTC and in= to dispc. The detection logic in `tidss_is_bridge_internal()` uses two heur= istics: - Check the bridge's `compatible` against a known list (`"ti,j721e-dsi"`) - Check if the bridge is a grandchild of DSS with parent named `"oldi-trans= mitters"` **Observations:** The approach of storing `dpi_output` in `dispc->vp_data[hw_videoport].dpi_o= utput` within `dispc_vp_setup()` is somewhat unusual =E2=80=94 `dispc_vp_se= tup()` is called on every atomic flush (not just modesets), so it re-writes= a value that was determined at init time and never changes. It would be cl= eaner to set this once at init time rather than on every frame update. This= isn't a bug, but it's architecturally odd. ```c +void dispc_vp_setup(struct dispc_device *dispc, u32 hw_videoport, + const struct drm_crtc_state *state, bool newmodeset, + bool dpi_output) +{ + dispc->vp_data[hw_videoport].dpi_output =3D dpi_output; ``` The `tidss_is_bridge_internal()` function correctly puts the of_node refere= nces. --- Generated by Claude Code Patch Reviewer