[PATCH AUTOSEL 7.0-6.1] drm/amd/display: Merge pipes for validate

[Sasha Levin <sashal@kernel.org>]

From: Harry Wentland <harry.wentland@amd.com>

[ Upstream commit 606f6b171326152ef08d0ef0ad49f52034edca07 ]

Validation expects to operate on non-split pipes. This is
seen in dcn20_fast_validate_bw, which merges pipes for
validation. We weren't doing that in the non-fast path
which lead to validation failures when operating with
4-to-1 MPC and a writeback connector.

Co-developed by Claude Sonnet 4.5

Assisted-by: Claude:claude-sonnet-4.5
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `drm/amd/display` (AMD display driver, DCN30
  specifically)
- **Action verb**: "Merge" (in the sense of merging split pipes before
  validation)
- **Summary**: Adds pipe merge step before validation in dcn30 non-fast
  path, matching the fast path behavior.

Record: [drm/amd/display] [merge/fix] [Add missing pipe merge call
before validation to match fast-validate path]

### Step 1.2: Tags
- **Fixes:** NONE (expected for autosel candidate)
- **Cc: stable:** NONE (expected for autosel candidate)
- **Co-developed by Claude Sonnet 4.5** - AI-assisted development
- **Assisted-by:** Claude:claude-sonnet-4.5
- **Reviewed-by:** Nicholas Kazlauskas (AMD display engineer)
- **Signed-off-by:** Harry Wentland (AMD display developer), Chuanyu
  Tseng, Alex Deucher (AMD DRM maintainer)
- **Reported-by:** NONE

Record: No Fixes tag, no Cc stable, no Reported-by. Reviewed by AMD
display expert. Signed by AMD DRM maintainer. No user bug reports.

### Step 1.3: Commit Body Text
The commit says: "Validation expects to operate on non-split pipes. This
is seen in dcn20_fast_validate_bw, which merges pipes for validation. We
weren't doing that in the non-fast path which lead to validation
failures when operating with 4-to-1 MPC and a writeback connector."

Bug: `dcn30_internal_validate_bw` passes split pipe configurations to
DML validation, but DML expects merged (non-split) pipes.
Symptom: Validation failures with 4-to-1 MPC split + writeback
connector.
Root cause: Missing `dcn20_merge_pipes_for_validate()` call that
dcn20_fast_validate_bw already has.

Record: [Validation expects non-split pipes; DCN30 non-fast path missed
merge call] [Validation failures with 4-to-1 MPC + writeback] [No
version info] [Same pattern as dcn20/dcn21 fast-validate]

### Step 1.4: Hidden Bug Fix Detection
This is NOT hidden - it clearly describes a validation failure bug and
the fix.

Record: [Explicit bug fix - validation failures on specific
configuration]

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: 1 file (`dcn30_resource.c`), +2 lines added (function call
  + blank line)
- **Functions modified**: `dcn30_internal_validate_bw`
- **Scope**: Single-file, single-line surgical fix

Record: [1 file, +2 lines] [dcn30_internal_validate_bw] [Single-line
surgical fix]

### Step 2.2: Code Flow Change
- **Before**: `dcn30_internal_validate_bw` immediately proceeds to set
  DML parameters and populate DML pipes without merging previously-split
  pipes.
- **After**: Before setting DML parameters, it calls
  `dcn20_merge_pipes_for_validate(dc, context)` to merge ODM-split and
  MPC-split pipes back into their head pipes, matching what
  `dcn20_fast_validate_bw` does.

The merge function (already existing in dcn20_resource.c, lines
1792-1849):
1. Merges ODM-split pipes by unlinking the chain
2. Merges MPC-split pipes by removing bottom_pipe entries
3. Both needed "since mode support needs to make the decision"

Record: [Before: validate with split pipes (wrong)] [After: merge pipes
first, then validate (correct, matching dcn20/dcn21)]

### Step 2.3: Bug Mechanism
This is a **logic/correctness fix**. The DML validation expects a single
non-split pipe view and makes its own split decisions. When pipes are
already split from a previous configuration, the validation gets
confused about pipe counts and resources, leading to false validation
failures.

Record: [Logic correctness bug] [DML fed split pipes when it expects
non-split pipes; fixes false validation failures]

### Step 2.4: Fix Quality
- **Obviously correct**: YES - directly matches the established pattern
  in `dcn20_fast_validate_bw` (line 2057) and dcn21's validate function
  (line 812)
- **Minimal/surgical**: YES - 1 line of actual code
- **Regression risk**: Extremely low - calling existing, well-tested
  function at the correct location
- **Red flags**: None

Record: [Obviously correct, matches established pattern] [No regression
risk from the fix itself]

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
- `dcn30_internal_validate_bw` was introduced by `5dba4991fd338d`
  (2020-05-21, "drm/amd/display: Add DCN3 Resource")
- The merge logic was available via `dcn20_merge_pipes_for_validate`
  since `ea817dd5ad7950` (2020-09-18, "drm/amd/display: add dcn21 bw
  validation")
- The bug has existed since DCN3 was first added (v5.9)
- `dcn20_resource.h` is already included by dcn30_resource.c (line 34)

Record: [Buggy code from 5dba4991fd338d, introduced in v5.9] [Bug
present in all stable trees with DCN3 support]

### Step 3.2: Fixes Tag
No Fixes: tag present. The bug was introduced when DCN3 resource was
added without the merge call.

### Step 3.3: Related Changes
- Commit `269c1d1443d668` (2025-05-14) changed `fast_validate` to `enum
  dc_validate_mode` - affects function signature but NOT the insertion
  point
- Commit `71c4ca2d3b079d` (2023-02-01) added `allow_self_refresh_only`
  parameter

Record: [Standalone fix, no prerequisites] [May need minor context
adjustment for older stable trees]

### Step 3.4: Author
Harry Wentland is a well-known AMD display developer and regular
contributor. Alex Deucher is the AMD DRM maintainer.

Record: [Authored by established AMD display developer, signed off by
subsystem maintainer]

### Step 3.5: Dependencies
The commit calls `dcn20_merge_pipes_for_validate()` which has existed
since v5.10+. The function is declared in `dcn20_resource.h` which is
already included. No new dependencies.

Record: [No dependencies, function already exists and is accessible]

## PHASE 4: MAILING LIST RESEARCH

I was unable to find the original patch submission on lore.kernel.org
due to anti-bot protections. Web searches found related AMD display work
by the same authors but not this specific patch.

Record: [UNVERIFIED - could not find original lore discussion] [No
stable-specific discussion found]

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
Only `dcn30_internal_validate_bw` is modified.

### Step 5.2: Callers
`dcn30_internal_validate_bw` is called from:
1. `dcn30_validate_bandwidth` (dcn30_resource.c:2091) - main validation
   entry point for DCN3.0
2. `dcn31_validate_bandwidth` (dcn31_resource.c:1812) - DCN3.1
3. `dcn314_validate_bandwidth` (dcn314_resource.c:1751) - DCN3.14
4. `dcn30_fpu.c` (lines 342, 634) - called in loops for dummy pstate and
   watermark calculations

This means the fix affects ALL DCN 3.x generations.

### Step 5.3-5.4: Call Chain
Display mode validation → `dcn30_validate_bandwidth` →
`dcn30_internal_validate_bw` → DML validation
This is triggered during every mode set/display configuration change.

Record: [Called during every mode set on DCN 3.0/3.1/3.14 hardware]
[Affects RDNA 2 GPUs (RX 6000), Rembrandt APUs, Phoenix APUs]

### Step 5.5: Similar Patterns
Confirmed: `dcn20_fast_validate_bw` at line 2057 and dcn21's validate
function at line 812 both already call `dcn20_merge_pipes_for_validate`
in the exact same position.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
DCN3 support (and `dcn30_internal_validate_bw`) has been present since
v5.9. All active stable trees (6.1.y, 6.6.y, 6.12.y) contain this code.

### Step 6.2: Backport Complications
The function signature changed over time:
- v6.1/v6.6: has `bool fast_validate` parameter
- v6.12+: has `enum dc_validate_mode validate_mode`
- The insertion point (after `if (!pipes) return false;`, before
  `maxMpcComb = 0`) is stable across versions
- Minor context adjustment may be needed for older trees

Record: [Likely clean apply or trivial conflict on most stable trees]

### Step 6.3: Related Fixes Already in Stable
No related fixes found for the same issue.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: drm/amd/display - display driver for AMD GPUs
- **Criticality**: IMPORTANT - AMD RDNA 2/3 GPUs are among the most
  widely deployed discrete GPUs
- DCN3.0 covers RX 6000 series, DCN3.1 covers Ryzen 6000 mobile APUs

### Step 7.2: Subsystem Activity
Very active subsystem with frequent changes.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users with AMD RDNA 2+ hardware (RX 6000 series, Ryzen 6000+ APUs) who
use display configurations triggering 4-to-1 MPC split with writeback.
This is driver-specific but on very popular hardware.

### Step 8.2: Trigger Conditions
- Requires 4-to-1 MPC pipe split (high resolution/bandwidth scenarios)
- Plus writeback connector active (screen capture, virtual display)
- Not a common everyday trigger, but can occur with specific display
  configurations

### Step 8.3: Failure Mode
Validation failure → mode set fails → display configuration rejected
Severity: MEDIUM-HIGH (can cause display output failure)

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: Prevents display validation failures on widely deployed
  hardware
- **Risk**: Extremely low (1-line change, calling existing well-tested
  function)
- **Ratio**: Strongly favorable for backporting

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real validation failure bug (display config rejection)
- Extremely surgical: 1 line of actual code
- Matches established pattern in dcn20/dcn21 (proven correct)
- Zero regression risk
- Affects widely deployed hardware (AMD RDNA 2+)
- Affects multiple DCN generations (3.0, 3.1, 3.14 all call this
  function)
- Bug has existed since v5.9 (long-standing)
- Reviewed by AMD display expert (Nicholas Kazlauskas)
- Signed off by AMD DRM maintainer (Alex Deucher)
- Function already exists and is included via header

**AGAINST backporting:**
- Specific trigger condition (4-to-1 MPC + writeback)
- No Fixes: tag, no Cc: stable (expected)
- No user bug reports (Reported-by)
- Writeback connector usage is relatively niche
- Co-developed with AI (unusual, though reviewed by expert)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - matches exact pattern in
   dcn20/dcn21
2. Fixes a real bug? **YES** - validation failures with specific
   configuration
3. Important issue? **MEDIUM** - display config rejection, not
   crash/security
4. Small and contained? **YES** - 1 line in 1 file
5. No new features or APIs? **YES** - just calls existing function
6. Can apply to stable? **YES** - insertion point is stable across
   versions

### Step 9.3: Exception Categories
Not an exception category - this is a standard bug fix.

### Step 9.4: Decision
The fix is extremely low risk (single function call, well-established
pattern) and prevents real validation failures on popular AMD hardware.
While the specific trigger (4-to-1 MPC + writeback) is not common in
everyday use, the fix has virtually zero regression potential and
corrects a clear inconsistency between the DCN20/21 and DCN30 validation
paths.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Nicholas Kazlauskas, SOBs from
  Wentland/Tseng/Deucher, Co-developed by AI
- [Phase 2] Diff analysis: +2 lines (1 function call + blank line) in
  dcn30_internal_validate_bw
- [Phase 2] Verified dcn20_fast_validate_bw at line 2057 already has
  identical call
- [Phase 2] Verified dcn21 validate function at line 812 already has
  identical call
- [Phase 3] git blame: dcn30_internal_validate_bw introduced in
  5dba4991fd338d (2020-05-21, v5.9)
- [Phase 3] git blame: dcn20_merge_pipes_for_validate introduced in
  ea817dd5ad7950 (2020-09-18)
- [Phase 3] Verified dcn30_resource.c includes dcn20/dcn20_resource.h at
  line 34
- [Phase 3] Verified function signature changes: validate_mode in
  269c1d1443d66 (2025), allow_self_refresh_only in 71c4ca2d3b079d (2023)
- [Phase 5] Confirmed callers: dcn30_validate_bandwidth, dcn31, dcn314,
  dcn30_fpu.c (multiple call sites)
- [Phase 5] Verified dcn20_merge_pipes_for_validate function body (lines
  1792-1849): merges ODM and MPC splits
- [Phase 6] Confirmed DCN3 present in stable trees since v5.9 (tag
  contains check)
- [Phase 6] maxMpcComb=0 line (context) confirmed present since v6.1
  (4931ce22eca6ed)
- UNVERIFIED: Could not access lore.kernel.org for mailing list
  discussion due to anti-bot protections
- UNVERIFIED: Could not find original patch submission via b4 dig or web
  search

**YES**

 drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c b/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
index 87b7b4ee04c64..b00054ea18178 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn30/dcn30_resource.c
@@ -1675,6 +1675,8 @@ noinline bool dcn30_internal_validate_bw(
 	if (!pipes)
 		return false;
 
+	dcn20_merge_pipes_for_validate(dc, context);
+
 	context->bw_ctx.dml.vba.maxMpcComb = 0;
 	context->bw_ctx.dml.vba.VoltageLevel = 0;
 	context->bw_ctx.dml.vba.DRAMClockChangeSupport[0][0] = dm_dram_clock_change_vactive;
-- 
2.53.0