Claude review: drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits

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

Patch Review

Good refactoring. The old code was:

```c
	if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
		return MODE_CLOCK_HIGH;
```

The new code:

```c
	const struct rzg2l_du_device_info *info = renc->info;

	if (info->mode_clock_min && mode->clock < info->mode_clock_min)
		return MODE_CLOCK_LOW;
	if (info->mode_clock_max && mode->clock > info->mode_clock_max)
		return MODE_CLOCK_HIGH;
```

**Issue 1 — Only r9a07g043u gets clock limits; r9a07g044 and r9a09g057 are left at 0:**

```c
 static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
 	...
+	.mode_clock_min = 20875,
+	.mode_clock_max = 83500,
 };
```

But `rzg2l_du_r9a07g044_info` and `rzg2l_du_r9a09g057_info` have no clock limits added, so `.mode_clock_min` and `.mode_clock_max` remain zero. The `0` check skips validation when these fields are zero, which means **the 83.5 MHz limit is silently removed for r9a07g044** (RZ/G2L). The old code applied the 83500 cap to all DPAD0 outputs. If RZ/G2L has the same pixel clock constraint (it likely does — it's the same DU IP), this is a regression.

The r9a09g057 (RZ/V2H) only has DSI0 output, so the old code never capped it anyway — no change there.

**The r9a07g044 needs `.mode_clock_max = 83500` added** to preserve the existing behavior.

**Issue 2 — The output-type check is dropped:**

The old code only applied the cap to `RZG2L_DU_OUTPUT_DPAD0`, not `DSI0`. The new code applies the clock limits regardless of output type. For r9a07g044 which has both DSI0 and DPAD0, the DSI output may have different clock constraints than DPAD. Moving to per-SoC limits loses the per-output-type granularity. This may be fine if the clock limits truly apply to the DU block itself rather than the output interface, but the commit message should address this design choice.

**Issue 3 — Storing `info` pointer in encoder:**

```c
+	renc->info = rcdu->info;
```

The encoder could access the device info through `renc->base.dev->dev_private` or similar DRM device traversal instead of storing a redundant pointer. However, this is a minor style point — the direct pointer is cleaner for the `mode_valid` hot path and matches patterns seen in other drivers. Acceptable.

---
Generated by Claude Code Patch Reviewer