Claude review: drm/rcar-du: dsi: Support DSC in the pipeline

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Status: Looks good, design comment**

The core problem is that `rcdu->dsi[]` stores the first bridge on the DSI output path. With DSC inserted, that's now the DSC bridge, not the DSI bridge. The `rcar_mipi_dsi_pclk_enable/disable` functions need the actual DSI bridge.

**Bridge resolution approach:**

```c
+static struct drm_bridge *
+rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge)
+{
+	if (bridge->funcs != &rcar_mipi_dsi_bridge_ops)
+		bridge = bridge->next_bridge;
+
+	if (!bridge || bridge->funcs != &rcar_mipi_dsi_bridge_ops)
+		return NULL;
+
+	return bridge;
+}
```

Using `bridge->funcs` pointer comparison to identify the DSI bridge is pragmatic and works for this hardware topology. The function handles both cases (direct DSI or DSC→DSI) cleanly. The `WARN_ON` at call sites ensures misconfigured DT would be noticed.

The forward declaration of `rcar_mipi_dsi_bridge_ops` is necessary since the struct definition is at line 923, after the functions using it. This is fine.

The comment block above `rcar_mipi_dsi_resolve_bridge` clearly documents the assumption that `next_bridge` is the DSI bridge, which is good.

One thing to note: `bridge->next_bridge` here refers to the `struct drm_bridge` field set during probe (in the DSC driver), not the chain built by `drm_bridge_attach`. This is correct because the DSC driver sets `dsc->bridge.next_bridge` in its probe function pointing to the DSI bridge.

---

---
Generated by Claude Code Patch Reviewer