Claude review: Re: [PATCH v2] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table

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

Patch Review

**Correctness of the formula:**

The computation mirrors the legacy driver at `dw-hdmi.c:673-675`:
```c
tmp = (u64)ftdms * n;
do_div(tmp, 128 * sample_rate);
cts = tmp;
```

The patch does the equivalent:
```c
u64 computed = (u64)tmds_char_rate * n;
do_div(computed, 128ULL * sample_rate);
cts = (unsigned int)computed;
```

This is correct. The `u64` cast prevents overflow since `tmds_char_rate` (up to ~600MHz) times `n` (up to ~10240) can exceed 32 bits.

**Guard condition:**

```c
if (!cts && n) {
```

This is the right check — only compute when `find_cts()` returned 0 (no table entry) and `n` is non-zero (so the division is meaningful). If `n` were somehow 0, the computation would produce 0 anyway, so the `n` guard is defensive but harmless.

**Minor observation — `dw_hdmi_qp_find_cts` can return `-ENOENT`:**

Looking at `dw_hdmi_qp_find_cts()` at line 338:
```c
default:
    return -ENOENT;
```

If an unsupported sample rate is passed (not 32k/44.1k/48k or their multiples), `find_cts()` returns `-ENOENT` (cast to `unsigned int`, a very large value). In that case `!cts` would be false, so the fallback wouldn't trigger — which is actually fine, since the CTS value would be garbage and the subsequent `dw_hdmi_qp_set_cts_n()` would enable CTS override with that garbage. However, this is a pre-existing bug in `dw_hdmi_qp_find_cts()` unrelated to this patch: the same problematic `-ENOENT` return exists for `dw_hdmi_qp_match_tmds_n_table()` too, and both pre-date this change. Not something this patch needs to fix.

**`128ULL` vs `128`:**

The patch uses `128ULL * sample_rate` in the divisor. The legacy driver uses `128 * sample_rate`. With `sample_rate` at most 192000, `128 * 192000 = 24,576,000`, well within 32-bit range, so the `ULL` suffix is unnecessary but harmless — it's slightly more defensive. Fine either way.

**Comment quality:**

The inline comment is longer than strictly necessary (9 lines), but given this is a non-obvious fallback path that compensates for hardware deficiency, the explanation of *why* auto-CTS fails and what the fix does is warranted. This is a case where the "why" truly is non-obvious.

**No issues found. The patch is correct and well-tested.**

---
Generated by Claude Code Patch Reviewer