Hi Mario, Alex, Alexander, Following up on this patch (c6a837088bed) with a regression report on a different Lenovo model.
On a ThinkPad T14s Gen 3 (AMD Radeon 680M / Rembrandt, DCN 3.1.2), this change causes the internal eDP panel to be capped at 60Hz even though the panel natively supports 90Hz. dm_helpers_read_local_edid() finds an ACPI-provided EDID via _DDC and uses it unconditionally, but on this machine that ACPI blob is a stale/incomplete copy of the panel's real EDID: it encodes only a 60Hz detailed timing, while a live DP AUX read of the same panel (Samsung Display, ATNA40YK08-0) returns 90Hz as the native/preferred timing plus 60Hz as a secondary mode. Both DTDs share the same pixel clock and htotal, so the ACPI copy looks like it was deliberately downclocked rather than being a different display. dmesg confirms the code path taken: amdgpu 0000:33:00.0: [drm] Using ACPI provided EDID for eDP-1 Booting with amdgpu.dcdebugmask=0x8000 (DC_DISABLE_ACPI_EDID) skips the ACPI EDID and forces the live AUX read, which correctly exposes 90Hz and reports the panel's real vendor (Samsung) instead of Lenovo's ACPI-authored EDID (manufacturer/model LEN 16713). Full writeup with the EDID diff (byte-level comparison of the ACPI blob vs. the live-read panel EDID), environment details, and repro steps is here: https://gitlab.freedesktop.org/drm/amd/-/work_items/5710 Since this same unconditional ACPI-EDID preference apparently fixes T14 Gen 4 but regresses T14s Gen 3, an unconditional preference in either direction doesn't seem to work for all eDP panels globally. Possible directions raised in the issue: fall back to ACPI only when the live AUX read fails (inverting current priority), prefer whichever source has more/higher-refresh timings, or gate the ACPI-EDID preference behind a DMI-based quirk table scoped to the models that actually need it. Thanks, Narek
