Skip to content

[BUG] [Regression] dcn32_program_compbuf_size REG_WAIT timeout persists on DCN 3.2 (RX 7900 XTX) after #810 fix — HDMI 4K@120Hz mode not exposed #1013

Description

@DegenerationDX

Pre-flight checklist

  • I have searched existing issues and this is not a duplicate.
  • I have read the Contributing Guidelines.
  • I have verified the issue is reproducible with the latest available CachyOS kernel.
  • I have tried to reproduce the issue on Arch Linux's linux kernel.

Upstream / vanilla kernel check

I have not tested with a vanilla/upstream kernel

Kernel variant

linux-cachyos (EEVDF, Clang)

System information (cachyos-bugreport.sh)

CPU: AMD Ryzen 7 7800X3D
- dGPU: AMD Radeon RX 7900 XTX (Navi 31, PCI 0000:03:00.0, PCI ID 0x1002:0x744c), 24GB VRAM, DCN 3.2
- iGPU: AMD Raphael (PCI 0000:18:00.0), also DCN 3.2 family, present but not driving the affected display
- RAM: 64GB
- Display: Samsung Q85A (2021 QLED, HDMI 2.1 capable) connected via HDMI-A-1
- Display server: KDE Plasma 6.7.4, KWin on Wayland

Manual system information (if cachyos-bugreport.sh is unavailable)


Bug description

This is the DCN 3.2 counterpart of #810, which was fixed and closed on 2026-07-07 for dcn31_program_compbuf_size (DCN 3.1, drivers/gpu/drm/amd/display/dc/hubbub/dcn31/dcn31_hubbub.c). That fix replaced the four open-coded REG_WAIT(DCHUBBUB_DETx_CTRL, ...) calls with dcn31_wait_for_det_apply() and was merged upstream via the amd-gfx patch "drm/amd/display: fix compressed buffer config routine waiting time".
However, that patch only touched dcn31_hubbub.c. The equivalent function for DCN 3.2 hardware, dcn32_program_compbuf_size() in drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.c, still contains the original unfixed code:

if (compbuf_size_segments > hubbub2->compbuf_size_segments) {
    REG_WAIT(DCHUBBUB_DET0_CTRL, DET0_SIZE_CURRENT, hubbub2->det0_size, 1, 100);
    REG_WAIT(DCHUBBUB_DET1_CTRL, DET1_SIZE_CURRENT, hubbub2->det1_size, 1, 100);
    REG_WAIT(DCHUBBUB_DET2_CTRL, DET2_SIZE_CURRENT, hubbub2->det2_size, 1, 100);
    REG_WAIT(DCHUBBUB_DET3_CTRL, DET3_SIZE_CURRENT, hubbub2->det3_size, 1, 100);
}


### Steps to reproduce

1.Boot CachyOS with kernel 7.2.0-1 or later (regression first appeared after upgrading from 7.1.8-1 to 7.2.0-1) on an RX 7900 XTX.
2.Connect a 4K120/HDMI 2.1 capable display (Samsung Q85A in this case) via HDMI.
3.Check dmesg for amdgpu/DC errors during boot.
4.Check available modes with kscreen-doctor -o or cat /sys/class/drm/card*-HDMI-A-*/modes.

### Expected behavior

The amdgpu driver should program the compressed buffer (DET) sizes without a register wait timeout, and the full set of modes the display's EDID advertises (including 3840x2160@120Hz / 4096x2160@120Hz) should be available to KWin/KScreen.

### Actual behavior

amdgpu 0000:03:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn32_program_compbuf_size line:148

(Also seen at line:147 in other reports.) The 4K@120Hz / 4K@100Hz modes are absent from the connector's mode list; the TV is capped at 3840x2160@60Hz / 4096x2160@60Hz despite EDID support for FRL-based 120Hz timings.

7.1.8-1: not affected. kscreen-doctor -o correctly lists 4096x2160@120.00, 3840x2160@120.00 (active, marked *), 3840x2160@119.88, 3840x2160@100.00, etc.
7.2.0-1: regression appears immediately after upgrading and rebooting. 4K modes capped at 60Hz, no 100/120Hz variants listed at all.
7.2.2-1: regression still present, unchanged from 7.2.0-1.
Reverting to 7.1.8-1 (reinstalling the cached package) immediately restores full 4K@120Hz mode availability, confirming this is kernel-side and not a KWin/Plasma or TV/cable/EDID issue.


### Logs / stack traces

```text

Additional system information

Port the same approach used to fix #810 to DCN 3.2: replace the four REG_WAIT(DCHUBBUB_DETx_CTRL, ...) calls in dcn32_program_compbuf_size() (drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.c) with an equivalent dcn32_wait_for_det_apply()-style helper, mirroring dcn31_wait_for_det_apply(). Happy to test a patch on this hardware if one is provided.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions