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

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

Patch Review

**Status: Looks good, well designed.**

This is the key refactoring patch. It replaces the hard-coded clock check:

```c
-	if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
+	if (route->mode_clock_min && mode->clock < route->mode_clock_min)
+		return MODE_CLOCK_LOW;
+	if (route->mode_clock_max && mode->clock > route->mode_clock_max)
 		return MODE_CLOCK_HIGH;
```

The per-output routing struct gets new fields:

```c
+	int mode_clock_min;
+	int mode_clock_max;
```

The existing SoC infos are updated with the same limits that were previously hard-coded (20875/83500 for RZ/G2UL and RZ/G2L DPAD0). The zero-means-unbounded convention is clean and natural for C static initializers.

**One observation:** `mode_clock_min` and `mode_clock_max` are declared as `int` but are always used as unsigned values (kHz). Using `unsigned int` would be more semantically correct, though it's a minor style point. The existing fields in the struct (`possible_outputs`, `port`) use `unsigned int`.

The approach of encoding constraints per-output rather than per-SoC is a good design choice — the cover letter mentions this was moved from `device_info` to `output_routing` in v3, which is the right level of granularity since different outputs on the same SoC could have different clock limits.

Note that the `r9a09g057` (RZ/V2H) info has no clock limits set (all zeros), so no mode validation occurs for that SoC's DSI0 output. This is presumably intentional since the DSI bridge driver would handle its own clock constraints.

---
Generated by Claude Code Patch Reviewer