Claude review: Revert "drm/msm/dpu: try reserving the DSPP-less LM first"

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

Patch Review

The commit message is clear about the motivation: blue screens on X1E80100 laptops, with a proper Fixes tag and Reported-by/Closes links.

The revert collapses the two-function design (`dpu_rm_find_lms` + `_dpu_rm_reserve_lms`) back into a single `_dpu_rm_reserve_lms` function. Looking at the diff:

> -static bool dpu_rm_find_lms(struct dpu_rm *rm,
> -			    struct dpu_global_state *global_state,
> -			    uint32_t crtc_id, bool skip_dspp,
> -			    struct msm_display_topology *topology,
> -			    int *lm_idx, int *pp_idx, int *dspp_idx)
> +static int _dpu_rm_reserve_lms(struct dpu_rm *rm,
> +			       struct dpu_global_state *global_state,
> +			       uint32_t crtc_id,
> +			       struct msm_display_topology *topology)

The separate `dpu_rm_find_lms` function is removed and its loop body is folded back into `_dpu_rm_reserve_lms`, with the `skip_dspp` filtering removed entirely:

> -		if (skip_dspp && to_dpu_hw_mixer(rm->mixer_blks[i])->cap->dspp) {
> -			DPU_DEBUG("Skipping LM_%d, skipping LMs with DSPPs\n", i);
> -			continue;
> -		}

This was the core of the optimization -- skipping DSPP-capable LMs when the topology doesn't need DSPPs. Removing this restores the original behavior of allocating LMs in their natural order.

> -	/* Try using non-DSPP LM blocks first */
> -	found = dpu_rm_find_lms(rm, global_state, crtc_id, !topology->num_dspp,
> -				topology, lm_idx, pp_idx, dspp_idx);
> -	if (!found && !topology->num_dspp)
> -		found = dpu_rm_find_lms(rm, global_state, crtc_id, false,
> -					topology, lm_idx, pp_idx, dspp_idx);

The two-pass fallback strategy (try without DSPP-capable LMs first, then fall back to any LM) is eliminated.

> -	for (i = 0; i < topology->num_lm; i++) {
> +	for (i = 0; i < lm_count; i++) {

This change in the reservation loop from `topology->num_lm` to `lm_count` is equivalent since the code reaches this point only when `lm_count == topology->num_lm` (verified by the check just above). No functional difference.

One minor note on the commit message: "It seems on later DPUs using higher LMs require some additional setup or conflicts with the hardware defaults" -- this is slightly awkward grammar ("using higher LMs require" could be "using higher LMs requires"), but it's understandable and this is a cosmetic observation.

No correctness issues found. The revert is a clean, mechanical undo of the original optimization and correctly restores the previous LM allocation behavior.

---
Generated by Claude Code Patch Reviewer