Claude review: drm/msm/dpu: Enable quad-pipe for DSC and dual-DSI case

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

Patch Review

**Review: Enables the feature, several issues.**

1. **Shadowed `kms` variable in `dpu_crtc_get_topology()`:** The function takes `struct dpu_kms *dpu_kms` as a parameter but also declares a local:
   ```c
   struct msm_drm_private *priv = crtc->dev->dev_private;
   struct dpu_kms *kms = to_dpu_kms(priv->kms);
   ```
   The local `kms` is used at line 1428 (`kms->perf.max_core_clk_rate`) while `dpu_kms` is used at line 1436 (`dpu_kms->catalog->caps->has_3d_merge`). Both should be the same object, but having two variables referring to the same thing is confusing and error-prone. The `dpu_kms` parameter should be used consistently, and the local `kms`/`priv` declarations should be removed.

2. **`dpu_encoder_helper_get_3d_blend_mode()` condition change:**
   ```c
   // Before:
   dpu_cstate->num_mixers == CRTC_DUAL_MIXERS
   // After:
   (dpu_cstate->num_mixers != 1)
   ```
   This changes the semantics. Previously, 3D merge was only used when exactly 2 mixers were present. Now it's used for any number of mixers > 1, including 3 or 4. For quad-pipe with 4 mixers, 3D merge should indeed be used for each pair, but this inline helper returns a single `BLEND_3D_H_ROW_INT` regardless of which mixer pair is being configured. Is this correct for the quad-pipe case where you'd want merge on pairs (0,1) and (2,3) but not across all 4? The callers need to handle this per-pair — verify they do.

3. **DSC topology logic:**
   ```c
   if (topology.num_dsc) {
       if (num_rt_intf == 1)
           topology.num_lm = 2;
       topology.num_dsc = topology.num_lm;
   }
   ```
   For single-interface DSC, this forces `num_lm = 2` regardless of the resolution check above. This seems intentional for backward compatibility with existing 2:2:1 DSC topologies. But for dual-interface with DSC, `topology.num_dsc` is set to `topology.num_lm`, which could be 2 or 4. When `num_lm = 2` and `num_rt_intf = 2`, you get `num_dsc = 2` (2:2:2). When `num_lm = 4`, you get `num_dsc = 4` (4:4:2). This seems correct.

   However, the original code had a guard: `if (topology.num_intf >= 2 || dpu_kms->catalog->dsc_count >= 2)` checking DSC block availability. The new code removes this check — if the hardware has fewer than `num_lm` DSC blocks, this could fail later during resource allocation. The resource manager should catch this, but the early check was a useful safety net.

4. **`STAGES_PER_PLANE` changed from 1 to 2 unconditionally** — this doubles the size of `pipe[]` and `pipe_cfg[]` arrays in `dpu_plane_state` for all platforms, even those that never use quad-pipe. This increases memory usage per plane state. For embedded/mobile this is a minor concern but worth noting.

5. **`MAX_CHANNELS_PER_ENC` changed from 2 to 4** — the `hw_lm` and `hw_mixer` arrays in `dpu_encoder_helper_reset_mixers()` are now sized 4. The `dpu_rm_get_assigned_resources()` call that fills these arrays must also be capable of returning up to 4 entries. Verify this is the case.

6. **`min(2, topology.num_lm)` type mismatch**: `topology.num_lm` is `u32` while `2` is `int`. The `min()` macro in the kernel requires matching types. This should use `min_t(u32, 2, topology.num_lm)` or similar, otherwise it may trigger a compile warning/error depending on kernel version and config.

Has Reviewed-by from Dmitry Baryshkov and Jessica Zhang. **The shadowed variable and `min()` type issues should be addressed.**

---
Generated by Claude Code Patch Reviewer