This commit fixes the issue. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/i915?id=062499cc4813b5a3cbed5dd4fbe0177265858450 drm/i915/mtl+: Enable PPS before PLL Enabling PPS after a display port's PLL is enabled leads to PLL / DDI BUF timeouts during system resuming after a long (> 45 mins) suspended state, at least on some ARL and MTL laptops, either all or some of them also containing an Nvidia GPU. Enabling PPS first and then the PLL fixes the problem for all the reporters. A similar issue is seen when enabling an external DP output on PHY B (vs. PHY A in the above eDP cases), where this change will not have any effect (since no PPS is used in that case). There isn't any direct connection between PPS and PLL, so the fix for eDP works by some side-effect only. However Bspec does seem to require enabling PPS first, so let's do that. Further investigation continues on the actual root cause and a cure for external panels. Fixes: 1a7fad2aea74 ("drm/i915/cx0: Enable dpll framework for MTL+") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16098 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16064 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16042 Cc: Mika Kahola <mika.kahola@intel.com> Cc: stable@vger.kernel.org # v7.0+ Tested-by: Jouni Högander <jouni.hogander@intel.com> Tested-by: Marco Nenciarini <mnencia@kcore.it> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260612172617.3427027-1-imre.deak@intel.com (cherry picked from commit 28783a274e886dd6da61419be6020bd9d0384e9f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167549 Title: ThinkPad P1 Gen 7 Meteor Lake — i915 PHY/DPLL failure after s2idle resume Status in linux package in Ubuntu: New Bug description: After resuming from an s2idle suspend of 30+ minutes, the i915 driver fails to re-enable the display. According to logs, the C10 PHY becomes completely unresponsive because its internal registers are inaccessible and this causes the entire display pipeline to remain stuck, sometimes for ~60 seconds or sometimes indefinitely (requiring a hard reset). GNOME Shell and input handling remain functional throughout; keystrokes typed during the black screen appear in the password box if/when the display eventually recovers. Short-duration suspends (<~2 minutes) resume cleanly without errors. The failure apparently correlates with suspend duration: during long s2idle, the display power well fully shuts down, and on resume the C10 PHY cold-start sequence fails. The bug does NOT reproduce on Windows (on the same laptop), suggesting this is an i915 driver bug, not a hardware or BIOS issue. ## My setup - Laptop: Lenovo ThinkPad P1 Gen 7 (model 21KV0025UK) - BIOS: N48ET34W (1.21), dated 2026-05-11 (current; no LVFS updates available) - iGPU: Intel Meteor Lake-P [Intel Arc Graphics] — PCI 8086:7d55 (rev 08) - Kernel driver: i915 - Panel: eDP-1, 3840x2400 (16:10), 4 lanes, C10 PLL at 540 MHz port clock - dGPU: NVIDIA AD107M [GeForce RTX 4060 Max-Q / Mobile] — PCI 10de:28a0 - Driver: nvidia 580.173.02 (open kernel module), nvidia-drm modeset=1 - NOTE: bug reproduces with and without nvidia loaded — not a factor - suspend mode: s2idle (platform supports only s2idle; no "deep"/S3 available) ## Software - OS: Ubuntu 24.04.5 LTS (Noble Numbat) - Kernel: 7.0.0-31-generic (#31~24.04.1-Ubuntu PREEMPT_DYNAMIC) (also reproduces on 7.0.0-30-generic) - Desktop: GNOME 46.0 on Wayland (GDM) - linux-firmware: 20240318.git3b128b60.0ubuntu3.1 - i915 firmware loaded: - DMC: i915/mtl_dmc.bin v2.21 - GuC: i915/mtl_guc_70.bin v70.36.0 (kernel recommends v70.53.0 but only 70.36.0 available — may or may not be related) - HuC: i915/mtl_huc_gsc.bin v8.5.4 ## To reproduce 1. Boot the system (any kernel 7.0.0-30 or 7.0.0-31) 2. Suspend (lid close or `systemctl suspend`) 3. Leave suspended for 30+ minutes (short suspends <2 min do NOT trigger it) 4. Resume (open lid / press key) 5. Observe: screen stays black for ~60 seconds (or never recovers and needs a hard reset) 6. Kernel log shows the error burst (see below) Suspend duration correlation: - Short suspends (1-2 min): 0 DRM errors, prompt in ~2s - Long suspends (30+ min): 19-97 DRM errors, 60s+ delay or hard reset ## What does NOT work I tried quite a few things, none of which succeeded: - Kernel update 7.0.0-30 → 7.0.0-31: no effect - i915.enable_psr=0 (PSR disabled): no effect - i915.enable_dc=0 (display C-states disabled): no effect - i915.enable_dsb=0 (Display State Buffer disabled): no effect (DSB timeouts disappeared from logs, but core PHY failure remained) - i915.disable_power_well=0 (keep power wells always on): no effect - NVIDIA driver loaded vs unloaded: no effect - nvidia_drm modeset=0 / modeset=1: no effect ## What DOES work - Hibernation: bypasses s2idle entirely (full boot from hibernation image re-initializes display from scratch). Zero DRM errors on resume. Confirmed working across multiple hibernate cycles. - Windows Modern Standby: does NOT reproduce the bug. ## What was NOT testable - xe driver: my laptop would not boot (apparently because the xe driver does not work in my kernel version. It refuses to probe even with xe.force_probe=7d55, requiring both xe.force_probe=7d55 AND i915.force_probe=!7d55. When loaded on 7.0.0-30, it registered only a generic card0-Unknown-1 connector with no eDP display output. Not a viable alternative without a newer kernel with proper MTL display support in xe. ## Root cause (from logs) On resume from long s2idle, the C10 PHY cold-start sequence fails at the hardware register level: 1. `Failed to bring PHY A to idle` PHY A cannot reach idle state 2. `PHY A Read 0c70 failed after 3 retries` PHY register 0c70 is completely inaccessible (returns no data) 3. `PHY A Write 0c70 failed after 3 retries` writes to the PHY also fail 4. `Timeout waiting for DDI BUF A to get active` DDI buffer never enables (depends on PHY being up) 5. `Timed out waiting for DP idle patterns` DP link training cannot proceed 6. C10 PLL state mismatch: expected clock 540000 (540 MHz), found 61440 (61.44 MHz = the idle/standby clock; PLL never re-enabled at full rate) All PLL registers found as 0x00 (zeroed/idle state) 7. `flip_done timed out` repeating every ~10s all atomic commits fail 8. `vblank wait timed out on crtc 0` pipe is dead, no vblanks The C10 PHY's control register interface (offset 0c70) is completely dead after long s2idle. No i915 kernel parameter that I tried can fix this. The PHY itself is in an inaccessible state. Since Windows handles the same hardware correctly, the i915 driver is missing a step in its PHY re-initialization sequence that the Windows Intel driver performs. From: journalctl -b 0 -k (With i915.enable_dc=0, i915.enable_dsb=0, i915.disable_power_well=0 all active) Code: Select all Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle. Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* PHY A Read 0c70 failed after 3 retries. Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* PHY A Write 0c70 failed after 3 retries. Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle patterns Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done timed out Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in pixel_rate (expected 572010, found 65082) Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in dpll_hw_state Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* expected: Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* cx0pll_hw_state: lane_count: 4, ssc_enabled: no, use_c10: yes, tbt_mode: no Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 540000, fracen: yes, Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* quot: 40960, rem: 0, den: 1, multiplier: 140, tx_clk_div: 0. Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: tx: 0x10, cmn: 0x21 Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0] = 0xf4, pll[1] = 0x0, pll[2] = 0xf8, pll[3] = 0x0 Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[16] = 0x84, pll[17] = 0x4f, pll[18] = 0xe5, pll[19] = 0x23 Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* found: Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_hw_state: clock: 61440, fracen: no, multiplier: 16, tx_clk_div: 0. Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* c10pll_rawhw_state: tx: 0x0, cmn: 0x0 Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* pll[0-19] = 0x0 (all zeros) Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 572010, found 65082) Sep 14 13:06:35 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in port_clock (expected 540000, found 61440) Sep 14 13:06:35 kernel: i915 0000:00.0: [drm] pipe state doesn't match! Sep 14 13:06:35 kernel: WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at verify_crtc_state+0x51b/0x6c0 [i915] Sep 14 13:06:35 kernel: intel_modeset_verify_crtc+0x70/0xb0 [i915] Sep 14 13:06:35 kernel: intel_atomic_commit_tail+0x8bb/0xc80 [i915] Sep 14 13:06:35 kernel: intel_atomic_commit+0x2c0/0x310 [i915] Sep 14 13:06:35 kernel: drm_atomic_commit+0xaf/0xf0 Sep 14 13:06:35 kernel: WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945 at verify_single_dpll_state+0x6c7/0x7e0 [i915] Sep 14 13:06:35 kernel: intel_modeset_verify_crtc+0x7b/0xb0 [i915] (flip_done timeouts repeat every ~10s:) Sep 14 13:06:45 i915 *ERROR* flip_done timed out Sep 14 13:06:45 i915 *ERROR* [CRTC:150:pipe A] commit wait timed out Sep 14 13:06:55 i915 *ERROR* flip_done timed out Sep 14 13:06:55 i915 *ERROR* [CONNECTOR:507:eDP-1] commit wait timed out Sep 14 13:07:06 i915 *ERROR* flip_done timed out Sep 14 13:07:06 i915 *ERROR* [PLANE:34:plane 1A] commit wait timed out ... Sep 14 13:07:57 i915 *ERROR* [CRTC:150:pipe A] flip_done timed out Sep 14 13:07:58 i915: vblank wait timed out on crtc 0 Sep 14 13:07:58 WARNING: drivers/gpu/drm/drm_vblank.c:1320 at drm_crtc_wait_one_vblank+0x18c/0x200 Sep 14 13:07:58 drm_client_modeset_wait_for_vblank+0x61/0x80 Sep 14 13:07:58 drm_fb_helper_damage_work+0x8c/0x1a0 (PM: suspend exit at 13:07:57, ~90s after the first PHY error at 13:06:35) Sep 14 13:07:57 kernel: PM: suspend exit Seems like it needs a kernel patch in the i915 display PHY resume code (drivers/gpu/drm/i915/display/intel_cx0_phy.c or similar), potentially adding a forced PHY reset or an alternative re-initialization sequence for the post-s2idle cold-start case. ## Workaround Hibernation works. I had to fiddle around with swap space and resume paramters to make this work but then `systemctl hibernate` works reliably with zero DRM errors on resume. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167549/+subscriptions
Комментариев нет:
Отправить комментарий