Bug 2464080

Maybe small addition, that if lid is closed and opened right away that still works, it seems like there is a certain "timeout" after which it reproduces. I'll try to gauge it today.

Created attachment 2138885 [details]
warning-log

Okay, issues reporduced after 1.5h of sleep. Here is a log that was running in a background: wake up attempt at 13:17

drm/xe does not allow opening new issues, but I've opened a new issue in drm/i915: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15992

Same behaviour happening also on i915 driver.

Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=145136493 a try for me and see if it resolves the issue?

(In reply to Justin M. Forbes from comment #5)
> Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=145136493 a
> try for me and see if it resolves the issue?

That's a custom rebuilt, right? I'm confused because I'm running 7.0.3-200.fc44.x86_64 already. I'll try to remove existing and try this one tomorrow.

Created attachment 2139524 [details]
wake up log entries

(In reply to Justin M. Forbes from comment #5)
> Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=145136493 a
> try for me and see if it resolves the issue?

Same issue, I'm afraid, here is a wake up log entries.

Upstream report is not accepted because Xe KMD for Meteor Lake is experimental :(

(In reply to pstourac from comment #4)
> Same behaviour happening also on i915 driver.

Can you maybe clone my issue and provide similar information for the i915 driver? https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15992#note_3456589

with  https://koji.fedoraproject.org/koji/taskinfo?taskID=145136493 kernel, after resume first try not wakes up, then after couple of minutes it wakes, it is not perfect, but there is deffinitely a progress.

## Additional occurrence of display initialization failure after suspend/resume

### Environment:
- Kernel: 7.0.3-200.fc44.x86_64
- linux-firmware: 20260309-1.fc44.noarch
- GPU: Intel Corporation Meteor Lake-P [Intel Arc Graphics] (rev 08)
- Display Server: Wayland
- Desktop: GNOME Shell
- Date: 2026-05-07 07:50:19 CEST

### Issue Description:
After resuming from suspend at 07:50:19, the display failed to initialize correctly. The system resumed successfully, but the display configuration was incorrect.

### Timeline and Errors:

**07:50:19** - System resumed from suspend
```
kernel: PM: suspend exit
kernel: i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.53.0
kernel: i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
```

**07:50:20** - First display errors appeared:
```
kernel: i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active
```

**07:50:22** - DisplayPort idle pattern timeout:
```
kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle patterns
```

**07:50:32** - Critical clock configuration mismatch:
```
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] flip_done timed out
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in pixel_rate (expected 154130, found 38971)
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 154130, found 38971)
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 154130, found 38971)
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in port_clock (expected 243000, found 61440)
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in dpll_hw_state
kernel: i915 0000:00:02.0: [drm] pipe state doesn't match!
```

**DPLL Configuration Mismatch Details:**

Expected state:
```
cx0pll_hw_state: lane_count: 2, ssc_enabled: no, use_c10: yes, tbt_mode: no
c10pll_hw_state: clock: 243000, fracen: yes
quot: 8192, rem: 0, den: 1, multiplier: 253, tx_clk_div: 2
```

Found state:
```
cx0pll_hw_state: lane_count: 2, ssc_enabled: no, use_c10: yes, tbt_mode: no
c10pll_hw_state: clock: 61440, fracen: no
multiplier: 16, tx_clk_div: 0
c10pll_rawhw_state: All PLL registers returned 0x0
```

**07:50:32** - DPLL verification warning:
```
WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945 at verify_single_dpll_state+0x177/0x650 [i915]
kernel: i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
```

**07:51:16 - 07:51:22** - Screen lock attempts failed due to display timeouts:
```
gsd-media-keys: Couldn't lock screen: Timeout
gsd-media-keys: Couldn't lock screen: GDBus.Error timeout
```

**07:51:41 - 07:52:02** - Additional flip_done timeouts:
```
kernel: i915 0000:00:02.0: [drm] *ERROR* flip_done timed out
kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] commit wait timed out
kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:506:eDP-1] commit wait timed out
kernel: i915 0000:00:02.0: [drm] *ERROR* [PLANE:33:plane 1A] commit wait timed out
kernel: i915 0000:00:02.0: [drm] pipe_off wait timed out
```

**07:52:02** - Transcoder disable warning:
```
WARNING: drivers/gpu/drm/i915/display/intel_display.c:363 at intel_disable_transcoder+0x312/0x3c0 [i915]
```

**07:52:03** - Cursor update failure:
```
gnome-shell: Cursor update failed: drmModeAtomicCommit: Invalid argument
```

### Resolution:
After manually locking and unlocking the screen (~07:54), the display reinitalized correctly and all issues were resolved. No further errors occurred after the lock/unlock cycle.

### Analysis:
The DPLL (Display Phase-Locked Loop) was not correctly initialized after resume, resulting in:
- Pixel clock set to ~25% of expected value (38971 kHz instead of 154130 kHz)
- Port clock set to ~25% of expected value (61440 kHz instead of 243000 kHz)
- All PLL hardware state registers effectively zeroed instead of proper configuration
- Display pipeline unable to complete atomic commits

The lock/unlock cycle triggered a full display reinitialization which properly configured the DPLL and restored normal operation.

### Current i915 Parameters:
```
enable_dc=-1 (auto)
enable_guc=3 (GuC submission and SLPC enabled)
```

This appears to be a display controller initialization race condition or state restoration issue specific to Meteor Lake GPUs during the resume path.

Hello, probably patch exists, would someone verify it or backport it?  


  This fixes the exact bug reported here:
  - PHY A Read 0c70 failed after 3 retries
  - DPLL hw state mismatch (expected 243000, found 61440)
  - Black screen on resume after suspend

  Patch URLs:
  1. http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg372073.html
  2. http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg372072.html
  3. http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg372071.html

  CI Report: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg372075.html
  Patchwork: https://patchwork.freedesktop.org/series/159540/

(In reply to pstourac from comment #11)
> Hello, probably patch exists, would someone verify it or backport it?  
> 
> 
>   This fixes the exact bug reported here:
>   - PHY A Read 0c70 failed after 3 retries
>   - DPLL hw state mismatch (expected 243000, found 61440)
>   - Black screen on resume after suspend

Those patches are in rawhide, does the rawhide kernel work for you?

https://koji.fedoraproject.org/koji/buildinfo?buildID=3000070

(In reply to Justin M. Forbes from comment #12)
> (In reply to pstourac from comment #11)
> > Hello, probably patch exists, would someone verify it or backport it?  
> > 
> > 
> >   This fixes the exact bug reported here:
> >   - PHY A Read 0c70 failed after 3 retries
> >   - DPLL hw state mismatch (expected 243000, found 61440)
> >   - Black screen on resume after suspend
> 
> Those patches are in rawhide, does the rawhide kernel work for you?
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=3000070

No, same behavior

Can you please test https://koji.fedoraproject.org/koji/taskinfo?taskID=145726679 and let me know if that helps?

(In reply to Justin M. Forbes from comment #14)
> Can you please test
> https://koji.fedoraproject.org/koji/taskinfo?taskID=145726679 and let me
> know if that helps?

The first test worked as expected. I'm waiting for another 30m to try again. What patches did you picked for this build?

(In reply to Gurenko Alex from comment #15)
> (In reply to Justin M. Forbes from comment #14)
> > Can you please test
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=145726679 and let me
> > know if that helps?
> 
> The first test worked as expected. I'm waiting for another 30m to try again.
> What patches did you picked for this build?

Yep, 2nd test passed as well, laptop wakes up with this kernel as expected.

(In reply to Justin M. Forbes from comment #14)
> Can you please test
> https://koji.fedoraproject.org/koji/taskinfo?taskID=145726679 and let me
> know if that helps?

Tested display in OFF mode >45 mins, no blank screen on wake, this fix works as expected.

Kernel 7.0.9-300 (WORKING):
  Contains 3 specific Intel i915 graphics patches that are not present in kernel 7.0.10-200:

  1. drm/i915/dp_tunnel: Don't update tunnel state during system resume (Imre Deak)
    - Key patch for proper resume - doesn't update DisplayPort tunnel state during suspend wake-up
  2. drm/i915/cx0: Clear response ready & error bit (Suraj Kandpal)
    - Clears error bits in CX0 PHY (DisplayPort physical layer)
  3. drm/i915/pps: Enable panel power earlier (Mika Kahola)
    - Enables panel power earlier in the initialization process

  Kernel 7.0.10-200 (NOT WORKING):
  Is clean upstream 7.0.10 without these Fedora-specific patches. The log shows these errors:

  i915 0000:00:02.0: [drm] *ERROR* Failed to get ACT after 3000 ms, last status: 04
  gnome-shell: Page flip failed: drmModeAtomicCommit: Invalid argument
  gnome-shell: Failed to post KMS update: drmModeAtomicCommit: Invalid argument

Finally. Kernel 7.0.10-201 works prefectly.

(In reply to pstourac from comment #19)
> Finally. Kernel 7.0.10-201 works prefectly.

Indeed, after two days with 7.0.10-201 kernel, it works as expected.