All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Novej Panjawani <novej.panjawani@gmail.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [BUG] i915/ADL-P eDP: link training exits with adj_req=0x11 unresolved, causing modeset loop on CMN14E7 (Dell Latitude 5430)
Date: Mon, 17 Aug 2026 15:08:54 +0300	[thread overview]
Message-ID: <ca8ac2afa85c8c47ea558e903a4952d2b000ba7e@intel.com> (raw)
In-Reply-To: <b4814185-1fe2-43a8-8d7c-11290c5e38f1@gmail.com>

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

      reply	other threads:[~2026-08-17 12:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-16 19:24 [BUG] i915/ADL-P eDP: link training exits with adj_req=0x11 unresolved, causing modeset loop on CMN14E7 (Dell Latitude 5430) Novej Panjawani
2026-08-17 12:08 ` Jani Nikula [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca8ac2afa85c8c47ea558e903a4952d2b000ba7e@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=novej.panjawani@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.