Claude review: drm/bridge: ite-it66121: Switch to the HDMI connector helpers

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

Patch Review

**Good:**
- Correctly adds `DRM_BRIDGE_OP_HDMI` to bridge ops and provides the required `vendor`/`product` fields.
- The infoframe write/clear callbacks properly replicate the existing register programming.
- Adding `DRM_DISPLAY_HDMI_STATE_HELPER` and `DRM_DISPLAY_HELPER` to Kconfig is correct.
- The NULL check added for `ctx->connector` in `it66121_bridge_enable` is a good defensive addition.

**Issue — `hdmi_tmds_char_rate_valid` ignores `tmds_rate`:**

The new callback signature receives a `tmds_rate` parameter but the implementation only validates `mode->clock`:

```c
static enum drm_mode_status
it66121_bridge_hdmi_tmds_char_rate_valid(const struct drm_bridge *bridge,
					 const struct drm_display_mode *mode,
					 unsigned long long tmds_rate)
{
	...
	max_clock = (ctx->bus_width == 12) ? 74250 : 148500;

	if (mode->clock > max_clock)
		return MODE_CLOCK_HIGH;

	if (mode->clock < 25000)
		return MODE_CLOCK_LOW;

	return MODE_OK;
}
```

The purpose of this callback is specifically to validate the TMDS character rate, not the pixel clock. The `tmds_rate` value may differ from the pixel clock (e.g., deep color modes multiply the rate). Looking at the reference `it6263` driver, it validates *both* `mode->clock` and `tmds_rate`. The `max_clock` values here (74250/148500 kHz) are pixel clock limits, while `tmds_rate` is in Hz. Consider converting the max clock limits to a TMDS rate check against `tmds_rate` as well, or at minimum validating `tmds_rate` against the maximum TMDS rate the hardware supports. As-is, this could allow modes that exceed the hardware's TMDS capability when deep color is in use. Not a regression since the old `mode_valid` had the same limitation, but this is the right time to fix it.

**Minor — no-op HDMI infoframe callbacks:**

```c
static int it66121_bridge_hdmi_clear_hdmi_infoframe(struct drm_bridge *bridge)
{
	return 0;
}

static int it66121_bridge_hdmi_write_hdmi_infoframe(struct drm_bridge *bridge,
						    const u8 *buffer, size_t len)
{
	return 0;
}
```

These are stubs that silently succeed. If the hardware genuinely can't send Vendor Specific InfoFrames, this is fine, but a brief comment explaining why would help future readers understand this is intentional rather than a TODO.

**Minor — locking in `it66121_bridge_hdmi_write_avi_infoframe`:**

The write callback takes `ctx->lock` internally. This is fine for now, but worth noting that `drm_atomic_helper_connector_hdmi_update_infoframes` (called from `atomic_enable`) will call both clear and write — the clear callback does *not* take the lock. This asymmetry is harmless since the clear only does a single `regmap_write` (which has its own lock), but it's worth being aware of.

---
Generated by Claude Code Patch Reviewer