# USB-C DP alt mode goes completely dead (no HPD, no connector events) after link-training failures on Lenovo Yoga 14s ITL 2021 — recovers only after full EC power drain

## Summary

On a Lenovo Yoga 14s ITL 2021 (TigerLake, Iris Xe, Thunderbolt 4), the USB-C
DisplayPort alt-mode path degrades in two stages:

1. Occasional i915 link-training failures through the Type-C retimer (LTTPR),
   which recover on retry (observed 2026-08-22 and 2026-09-02).
2. A final, persistent state where **both** Type-C ports stop reporting
   display connectivity entirely: no HPD reaches i915, all DRM connectors stay
   `disconnected`, and the kernel generates **zero** uevents (usb / drm /
   typec / thunderbolt) on cable plug/unplug. PD charging over the same cable
   keeps working (the EC still reports adapter online/offline), so the PD
   controller is alive but the display/USB-data path is not negotiated.

The dead state survives normal reboot and even full shutdown, and is
identical on two different kernel versions (7.1.11 and 7.2.2). It is only
recoverable by a **full EC power drain** (shutdown, remove all cables, hold
the power button ~30–40 s to drain the board), after which the monitor trains
immediately and works flawlessly.

**Request:** a kernel-side recovery path for this wedge (e.g. retimer/mux
reset via the TCSS/PMC when link training repeatedly fails on a TC port),
instead of leaving the port unusable until the user performs a hardware power
drain. Secondary: investigate `ucsi_acpi` never probing the `USBC000` HID
device described below.

## Environment

| Item | Value |
|---|---|
| Machine | Lenovo Yoga 14s ITL 2021 (82G2), INSYDE UEFI 372.00 |
| APU | Intel TigerLake-LP GT2 Iris Xe (8086:9a49), driver i915 |
| OS | Omarchy 4.0.0.r191 (Arch-based, Hyprland 0.56.2) |
| Kernels tested | 7.1.11-arch1-1 and 7.2.2-arch1-1 (fault identical on both) |
| Monitor | CSF MX3228, 3840x2160@120–160 Hz, USB-C DP alt mode (single cable, also verified working on a Mac with the same cable) |
| Connection | USB-C DP alt mode, direct, no dock; monitor also provides PD charging to the laptop |

## Evidence timeline (all times CST)

### Stage 1 — intermittent link-training failures (monitor recovers on retry)

```
2026-08-22 22:09:24 kernel: i915 0000:00:02.0: [drm] *ERROR*
    [CONNECTOR:610:DP-2][ENCODER:609:DDI TC2/PHY TC2][DPRX]
    Can't reduce link training parameters after failure

2026-09-02 09:46:45 kernel: i915 0000:00:02.0: [drm] *ERROR*
    [CONNECTOR:610:DP-2][ENCODER:609:DDI TC2/PHY TC2][LTTPR 1]
    Failed to get link status
```

The 2026-09-02 error fires at boot time (monitor already attached) and the
link recovers on retry — the monitor then worked all day.

### Stage 2 — permanent wedge (2026-09-03 21:46 → 2026-09-06 22:47)

First boot after a full system upgrade and subsequent reboot (the upgrade to
7.2.2 was performed *while the external monitor was working*, so the failing
reboot was the first cold boot with the new kernel). From this point:

- All connectors permanently `disconnected` with the cable attached:

  ```
  card1-DP-1: disconnected
  card1-DP-2: disconnected
  card1-DP-3: disconnected
  card1-DP-4: disconnected
  card1-eDP-1: connected
  ```

- `udevadm monitor --kernel --subsystem-match=usb --subsystem-match=drm
  --subsystem-match=typec --subsystem-match=thunderbolt` records **zero**
  events across multiple plug/unplug cycles and a port swap.
- PD layer still alive: unplugging/replugging fires the EC adapter
  online/offline transition (`ADP1` in `/sys/class/power_supply`, desktop
  power notification), battery keeps charging from the monitor.
- Fault state is identical:
  - on kernel **7.1.11-arch1-1** (the version the monitor worked on before)
    and on **7.2.2-arch1-1**,
  - on **both** Type-C ports (DDI TC1/TC2 PHYs),
  - after normal reboot and after full shutdown.
- No error is logged anywhere in the kernel ring buffer during the wedged
  plug attempts — the failure is silent at the kernel level.

### Recovery — EC power drain (2026-09-06 22:48)

Power off, remove all cables, hold the power button ~30–40 s (EC/board
discharge), boot, replug the monitor: `card1-DP-2` reports `connected`
immediately and Hyprland brings the display up at native
[email protected] Hz, scale 1.6, with correct rendering (verified by
screenshot: crisp text at native 4K, no scaling artifacts).

## Type-C subsystem observations during the wedged state (both kernels)

- Modules `ucsi_acpi`, `typec_ucsi`, `typec`, `thunderbolt` are loaded, but
  `/sys/class/typec/` is empty — no connector objects ever registered.
- The ACPI UCSI device exists and claims to be enabled:

  ```
  /sys/devices/platform/USBC000:00
  modalias = acpi:USBC000:PNP0CA0:
  firmware_node/status = 15 (0x0F: present & enabled)
  ```

  but `ucsi_acpi` (whose match table contains only `PNP0CA0`) **never probes
  it** — no `driver` symlink, no probe attempt logged, on any boot (checked
  back through 2026-09-01, including boots when the monitor worked).
- Attempting a manual bind fails oddly:

  ```
  $ echo USBC000:00 | sudo tee /sys/bus/platform/drivers/ucsi_acpi/bind
  tee: .../bind: No such device        # -ENODEV
  ```

  Even after setting `driver_override` to `ucsi_acpi` (verified written back
  in sysfs), the bind store still returns `-ENODEV` and no probe attempt is
  logged. Since `platform_match()` short-circuits on `driver_override`, the
  device appears to never even reach driver attach — possibly a driver-core
  / ACPI-platform matching issue worth a look independently of the wedge.
- `/sys/bus/thunderbolt/devices/` shows only the two host routers (`0-0`,
  `1-0`); the Thunderbolt xHCI (0000:00:0d.0) enumerates no devices; the
  chipset xHCI (0000:00:14.0) works normally throughout (all other USB
  devices unaffected).

## Interpretation (hypothesis, clearly separated from facts above)

The facts are consistent with the TigerLake TCSS/retimer (or the EC-managed
power rail feeding it) latching into a state where it stops reporting attach
events upstream, while the PD/EC layer keeps functioning. Normal reboot does
not reset it because standby power keeps the EC/retimer state alive. The
escalating pattern (occasional LTTPR training failures → permanent silence)
suggests a firmware/hardware robustness gap that the kernel could help with.

**Requested fixes:**

1. A recovery path in the kernel for TC ports that repeatedly fail link
   training through an LTTPR: e.g. trigger a retimer/mux re-initialization
   (ACPI `_DSM` / PMC frame / UCSI connector reset) after N consecutive
   failures, and log a clear diagnostic instead of failing silently.
2. Investigate why `ucsi_acpi` never probes the `USBC000` HID device even
   though it is present and `_STA`-enabled, and why manual bind via
   `driver_override` returns `-ENODEV` with no probe attempt.

## Workaround

Full EC power drain: shut down, unplug everything (AC + all cables), hold the
power button for 30–40 s, boot, replug the display. Recovers instantly,
confirmed at 4K@120 Hz.