Claude review: drm/msm/dpu: fix video mode DSC INTF timing width for non 8 bit panels

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

Patch Review

**The fix itself is mathematically correct.** The compressed INTF timing width should represent how many pixel-clock cycles are needed to output the compressed data. The INTF outputs 3 bytes (24 bits) per pixel clock, so:

```
compressed_width = (width * bpp_compressed) / 24
```

The previous formula `width * bpp_compressed / (bits_per_component * 3)` happens to equal the same thing for 8-bit panels (8×3=24) but produces wrong results for 10-bit panels (10×3=30), which explains the FIFO errors.

**Consistency concern — `dsi_adjust_pclk_for_compression()` at `dsi_host.c:590-591`:**

```c
int new_hdisplay = DIV_ROUND_UP(mode->hdisplay * drm_dsc_get_bpp_int(dsc),
		dsc->bits_per_component * 3);
```

This function uses the **exact same** `bits_per_component * 3` divisor for pclk rate adjustment. If the reasoning in this patch is correct (the divisor should always be 24), then this function likely needs the same fix. Not addressing it could mean the pixel clock rate is calculated incorrectly for 10-bit DSC panels, potentially causing timing issues even after this INTF fix. At minimum, the commit message should explain why this instance is different or add a note that it will be addressed separately.

**Commit message could be improved:** The patch is described as fixing "video mode DSC INTF timing" but the rationale of "matches downstream" is somewhat weak on its own. It would benefit from a brief explanation of *why* 24 is correct (the INTF always outputs 3 bytes per clock regardless of source bit depth), rather than just deferring to downstream behavior.

**Nit:** This patch could arguably carry a `Fixes:` tag pointing to the commit that introduced the `bits_per_component * 3` formula, which would help with backporting to stable kernels.

---
Generated by Claude Code Patch Reviewer