[BUG] i915/ADL-P eDP: link training exits with adj_req=0x11 unresolved, causing modeset loop on CMN14E7 (Dell Latitude 5430)

[BUG] i915/ADL-P eDP: link training exits with adj_req=0x11 unresolved, causing modeset loop on CMN14E7 (Dell Latitude 5430)

[Novej Panjawani]

## Summary

After boot and after any display mode change (HDMI connect/disconnect), 
the internal eDP display on this Dell Latitude 5430 (ADL-P, Intel Iris 
Xe 46A8) enters an **infinite modeset loop** that repeats every ~2 
seconds: backlight off → pipe disabled → link retrain → pipe enabled → 
backlight on → repeat. This produces continuous visible black-screen 
flashing. The loop self-resolves after ~5–15 minutes (thermal 
stabilization of the eDP connection), and is immediately re-triggered by 
any subsequent mode change.

External HDMI display is not affected.

## Hardware / Environment

| | |
|---|---|
| **System** | Dell Latitude 5430 |
| **GPU** | Intel Alder Lake-P, Iris Xe Graphics — PCI `0000:00:02.0`, 
Device ID `0x46A8` |
| **Panel** | Chimei Innolux CMN14E7 — 14" 1920×1080, eDP 1.4, EDID 1.4 |
| **Kernel** | `6.18.40-1-cachyos-lts` (clang 22.1.8, LLD 22.1.8) |
| **i915** | 1.6.0 — GuC 70.49.4, DMC adlp_dmc.bin v2.20, HuC 7.9.3 |
| **BIOS** | Dell 1.36.0 (2025-12-23) — latest per fwupd |

## Root Cause

With `drm.debug=0x04`, the following loop is captured every ~2 seconds:

1. `intel_dp_start_link_train` uses **vswing 0/0/0/0, pre-emph 0/0/0/0** 
at `LINK_BW_SET=0x0a` (HBR / 2.7 Gbps), 2 lanes
2. TPS1 and TPS2 complete — `"Channel EQ done. DP Training successful"`
3. Pipe A and backlight are enabled (PWM = 23718)
4. ~2 seconds later, link status check:
    - Read 1: `align:0x80 sink:0x3 adj_req0_1:0x11` — aligned, but panel 
requesting vswing level 1
    - Read 2: `align:0x0 sink:0x1 adj_req0_1:0x11` — **alignment lost, 
symbol lock lost**
5. Driver detects link loss → full modeset (backlight off, pipe disabled)
6. Repeat from step 1

**`adj_req0_1=0x11` (vswing level 1 requested for lanes 0/1) appears in 
every DPCD read throughout the flicker window.** The driver exits 
training while adj_req is non-zero and does not apply the requested 
levels to the operational link. The panel cannot sustain HBR at level 0, 
degrades within ~2 seconds, fires IRQ_HPD, the driver responds with a 
full modeset, and the cycle repeats.

## Debug Log (one complete cycle)

Captured with `drm.debug=0x04`:

```
i915: [drm:intel_dp_start_link_train] Using LINK_BW_SET value 0a
i915: [drm:intel_dp_set_signal_levels] 8b/10b, lanes: 2, vswing levels: 
0/0/0/0, pre-emphasis levels: 0/0/0/0
i915: [drm:intel_dp_link_train_phy] Clock recovery OK
i915: [drm:intel_dp_link_train_phy] Channel EQ done. DP Training successful
i915: [drm:intel_dp_link_train_phy] Link Training passed at link rate = 
270000, lane count = 2
i915: enabling pipe A
i915: [drm:cnp_enable_backlight] set backlight PWM = 23718

-- ~2 seconds --

i915: [drm:intel_dp_dump_link_status] ln0_1:0x73 align:0x80 sink:0x3 
adj_req0_1:0x11   <-- link ok, but adj_req non-zero
i915: [drm:intel_dp_dump_link_status] ln0_1:0x73 align:0x0 sink:0x1 
adj_req0_1:0x11   <-- link lost

i915: [drm:cnp_disable_backlight] set backlight PWM = 0
i915: [drm:intel_disable_transcoder] disabling pipe A
i915: [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 4 - cnt: 10
i915: [drm:intel_dp_hpd_pulse] ignoring long hpd on eDP [ENCODER:262:DDI 
A/PHY A]

-- repeat every ~2 seconds --
```

## Reproduction

1. Append `drm.debug=0x04` to kernel cmdline, reboot
2. `journalctl -k -f | grep -E 
"link_train|dump_link|hpd|backlight|transcoder"`
3. Cycle appears within seconds of display init, repeats every ~2 seconds
4. After 5–15 min, cycle stops (thermal stabilization)
5. Retrigger: unplug external display → cycle immediately resumes

## Expected Behaviour

Either:
- **(a)** The TPS2 loop should continue iterating and updating 
vswing/pre-emph until `adj_req` is zero before declaring training 
successful; or
- **(b)** After training exits, the driver should apply the final 
`adj_req` vswing values to the DDI buffer translation used for normal 
operation

## Attempted Workarounds (all ineffective)

None of the following affect link training vswing behavior:
- `i915.enable_psr=0`, `i915.enable_panel_replay=0`
- `i915.enable_dc=0`, `i915.enable_sagv=0`, `i915.enable_fbc=0`, 
`i915.enable_dsb=0`
- `i915.edp_vswing=2` — selects 400 mV DDI translation table but does 
not force vswing level 1 in the training loop
- `i915.enable_rc6=0` — silently ignored ("unknown parameter"); GuC RC 
remains active
- `xe.force_probe=46a8` — xe exhibits a separate fatal bug: continuous 
GTT plane faults in stolen framebuffer memory (~300K–600K suppressed 
callbacks per 5 seconds)

## Notes

- Issue self-resolves after thermal warmup, strongly suggesting the 
physical link is borderline at HBR/level-0 — applying level 1 should 
resolve it permanently
- BIOS 1.36.0 is the latest (confirmed via fwupd)
- External HDMI (pipe B) is unaffected throughout

Re: [BUG] i915/ADL-P eDP: link training exits with adj_req=0x11 unresolved, causing modeset loop on CMN14E7 (Dell Latitude 5430)

[Jani Nikula]

On Sun, 16 Aug 2026, Novej Panjawani <novej.panjawani@gmail.com> wrote:
> ## Summary
>
> After boot and after any display mode change (HDMI connect/disconnect), 
> the internal eDP display on this Dell Latitude 5430 (ADL-P, Intel Iris 
> Xe 46A8) enters an **infinite modeset loop** that repeats every ~2 
> seconds: backlight off → pipe disabled → link retrain → pipe enabled → 
> backlight on → repeat. This produces continuous visible black-screen 
> flashing. The loop self-resolves after ~5–15 minutes (thermal 
> stabilization of the eDP connection), and is immediately re-triggered by 
> any subsequent mode change.

Please file a bug as described at [1].

BR,
Jani.


[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html


>
> External HDMI display is not affected.
>
> ## Hardware / Environment
>
> | | |
> |---|---|
> | **System** | Dell Latitude 5430 |
> | **GPU** | Intel Alder Lake-P, Iris Xe Graphics — PCI `0000:00:02.0`, 
> Device ID `0x46A8` |
> | **Panel** | Chimei Innolux CMN14E7 — 14" 1920×1080, eDP 1.4, EDID 1.4 |
> | **Kernel** | `6.18.40-1-cachyos-lts` (clang 22.1.8, LLD 22.1.8) |
> | **i915** | 1.6.0 — GuC 70.49.4, DMC adlp_dmc.bin v2.20, HuC 7.9.3 |
> | **BIOS** | Dell 1.36.0 (2025-12-23) — latest per fwupd |
>
> ## Root Cause
>
> With `drm.debug=0x04`, the following loop is captured every ~2 seconds:
>
> 1. `intel_dp_start_link_train` uses **vswing 0/0/0/0, pre-emph 0/0/0/0** 
> at `LINK_BW_SET=0x0a` (HBR / 2.7 Gbps), 2 lanes
> 2. TPS1 and TPS2 complete — `"Channel EQ done. DP Training successful"`
> 3. Pipe A and backlight are enabled (PWM = 23718)
> 4. ~2 seconds later, link status check:
>     - Read 1: `align:0x80 sink:0x3 adj_req0_1:0x11` — aligned, but panel 
> requesting vswing level 1
>     - Read 2: `align:0x0 sink:0x1 adj_req0_1:0x11` — **alignment lost, 
> symbol lock lost**
> 5. Driver detects link loss → full modeset (backlight off, pipe disabled)
> 6. Repeat from step 1
>
> **`adj_req0_1=0x11` (vswing level 1 requested for lanes 0/1) appears in 
> every DPCD read throughout the flicker window.** The driver exits 
> training while adj_req is non-zero and does not apply the requested 
> levels to the operational link. The panel cannot sustain HBR at level 0, 
> degrades within ~2 seconds, fires IRQ_HPD, the driver responds with a 
> full modeset, and the cycle repeats.
>
> ## Debug Log (one complete cycle)
>
> Captured with `drm.debug=0x04`:
>
> ```
> i915: [drm:intel_dp_start_link_train] Using LINK_BW_SET value 0a
> i915: [drm:intel_dp_set_signal_levels] 8b/10b, lanes: 2, vswing levels: 
> 0/0/0/0, pre-emphasis levels: 0/0/0/0
> i915: [drm:intel_dp_link_train_phy] Clock recovery OK
> i915: [drm:intel_dp_link_train_phy] Channel EQ done. DP Training successful
> i915: [drm:intel_dp_link_train_phy] Link Training passed at link rate = 
> 270000, lane count = 2
> i915: enabling pipe A
> i915: [drm:cnp_enable_backlight] set backlight PWM = 23718
>
> -- ~2 seconds --
>
> i915: [drm:intel_dp_dump_link_status] ln0_1:0x73 align:0x80 sink:0x3 
> adj_req0_1:0x11   <-- link ok, but adj_req non-zero
> i915: [drm:intel_dp_dump_link_status] ln0_1:0x73 align:0x0 sink:0x1 
> adj_req0_1:0x11   <-- link lost
>
> i915: [drm:cnp_disable_backlight] set backlight PWM = 0
> i915: [drm:intel_disable_transcoder] disabling pipe A
> i915: [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 4 - cnt: 10
> i915: [drm:intel_dp_hpd_pulse] ignoring long hpd on eDP [ENCODER:262:DDI 
> A/PHY A]
>
> -- repeat every ~2 seconds --
> ```
>
> ## Reproduction
>
> 1. Append `drm.debug=0x04` to kernel cmdline, reboot
> 2. `journalctl -k -f | grep -E 
> "link_train|dump_link|hpd|backlight|transcoder"`
> 3. Cycle appears within seconds of display init, repeats every ~2 seconds
> 4. After 5–15 min, cycle stops (thermal stabilization)
> 5. Retrigger: unplug external display → cycle immediately resumes
>
> ## Expected Behaviour
>
> Either:
> - **(a)** The TPS2 loop should continue iterating and updating 
> vswing/pre-emph until `adj_req` is zero before declaring training 
> successful; or
> - **(b)** After training exits, the driver should apply the final 
> `adj_req` vswing values to the DDI buffer translation used for normal 
> operation
>
> ## Attempted Workarounds (all ineffective)
>
> None of the following affect link training vswing behavior:
> - `i915.enable_psr=0`, `i915.enable_panel_replay=0`
> - `i915.enable_dc=0`, `i915.enable_sagv=0`, `i915.enable_fbc=0`, 
> `i915.enable_dsb=0`
> - `i915.edp_vswing=2` — selects 400 mV DDI translation table but does 
> not force vswing level 1 in the training loop
> - `i915.enable_rc6=0` — silently ignored ("unknown parameter"); GuC RC 
> remains active
> - `xe.force_probe=46a8` — xe exhibits a separate fatal bug: continuous 
> GTT plane faults in stolen framebuffer memory (~300K–600K suppressed 
> callbacks per 5 seconds)
>
> ## Notes
>
> - Issue self-resolves after thermal warmup, strongly suggesting the 
> physical link is borderline at HBR/level-0 — applying level 1 should 
> resolve it permanently
> - BIOS 1.36.0 is the latest (confirmed via fwupd)
> - External HDMI (pipe B) is unaffected throughout
>

-- 
Jani Nikula, Intel