Apple Studio Display (2026, Thunderbolt 5) — DP tu nnel torn down every few minutes on Intel TB4 host

Summary
-------

An Apple Studio Display (2026 model, Thunderbolt 5) connected to an Intel
Arrow Lake-H host with integrated Thunderbolt 4 loses its DisplayPort
tunnel every 2-5 minutes under normal desktop use. The screen goes black
for ~2 s, occasionally for several minutes. The Thunderbolt link itself,
the tunnelled USB3 and the tunnelled PCIe stay up throughout -- only the
DP tunnels are torn down and re-established.

The previous Studio Display model (2022, Thunderbolt 3) on the same host,
same port, same cable, same kernel does not show the problem.

Hardware
--------

Host:        Intel NUC 15 Pro "Cyber Canyon" (NUC15CRKU5), Core Ultra 5 225H
Host TB:     integrated, 8086:7ec2 / 8086:7ec3, host router generation 4
GPU:         Intel Arc 130T/140T (8086:7d51), i915
Kernel:      7.1.4-arch1-1 (Arch Linux)
Compositor:  Hyprland / aquamarine (Wayland, atomic KMS)

Failing display -- Apple Studio Display 2026
- EDID: manufacturer APP, model 44614, made week 1 of 2026
- TB device 0x8025, generation 4, 20.0 Gb/s x 2 lanes, NVM 64.81
- contains an Intel JHL9480 (Barlow Ridge, TB5) -- appears as
  8086:5786 PCIe switch behind the tunnel
- firmware updated via macOS immediately before these traces; no change

Working reference -- Apple Studio Display 2022
- EDID: manufacturer APP, model 44602, made week 7 of 2022
- TB device 0x801f, generation 3, NVM 67.0

Symptom
-------

Reproducible within minutes by scrolling bright web pages. Frequency under
load is one event every 2-5 minutes. Recovery is usually ~2 s; three events
during the session took between 2 and 3 minutes.

Only the Studio Display blanks. A second monitor on HDMI is unaffected.

Trace
-----

drm.debug=0x104 plus "module thunderbolt +p". A single event:

  i915 0000:00:02.0: [drm:xelpdp_pica_irq_handler] pica hotplug event received,
                     stat 0x0000000c, pins 0x00001800, long 0x00001800
  i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
                     [ENCODER:521:DDI TC3/PHY TC3] - long
  i915 0000:00:02.0: [drm:drm_dp_dpcd_access] AUX USBC3/DDI TC3/PHY TC3:
                     Too many retries, giving up. First error: -6
  i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
                     [ENCODER:549:DDI TC4/PHY TC4] - long
  i915 0000:00:02.0: [drm:intel_tc_port_reset_mode] Port G/TC#4:
                     TC port mode reset (disconnected -> tbt-alt)
  i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:5] destroying
  i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:6] destroying

Thunderbolt side of the same event:

  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:11
  thunderbolt 0000:00:0d.3: 1:11: DP OUT resource unavailable: adapter unplug
  thunderbolt 0000:00:0d.3: 0:5 <-> 1:11 (DP): deactivating
  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12
  thunderbolt 0000:00:0d.3: deactivating Video path from 0:5 to 1:11
  thunderbolt 0000:00:0d.3: 0:5: detached from bandwidth group 1
  thunderbolt 0000:00:0d.3: 0: released DP resource for port 5
  thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): DPRX read timeout

The "hot unplug event" originates from the device router; the host acks it
and tears the tunnels down. "DPRX read timeout" recurs on every event.

In one earlier trace the teardown was preceded by a bandwidth-allocation
request from the display asking for zero:

  thunderbolt 0000:00:0d.3: acking DP_BW (0x20) notification on 0
  thunderbolt 0000:00:0d.3: 0:6: requested bandwidth 0 Mb/s
  thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): bandwidth allocation
changed to 0/0 Mb/s
  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12

Later events start directly at the active adapter 1:11 with no such
prelude, also with bw_alloc_mode=N.

Possibly relevant: tunnel topology differs between the two models
-----------------------------------------------------------------

Both displays expose a 2x1 tiled EDID (2560x2880 per tile).

2026 model -- i915 drives the full 5120x2880 through a single tunnel at
HBR3; the second DP tunnel exists but never carries a stream:

  0:5 <-> 1:11 (DP): consumed bandwidth 0/22500 Mb/s      <- carries all of 5K
  0:6 <-> 1:12 (DP): consumed bandwidth 0/0 Mb/s          <- idle
  port_clock=810000, lane_count=4

2022 model -- driven as two real tiles, both tunnels carrying video:

  0:5 <-> 1:10 (DP): consumed bandwidth 0/17000 Mb/s
  0:6 <-> 1:11 (DP): estimated bandwidth 19000 Mb/s
  port_clock=540000, lane_count=4

The idle second tunnel of the 2026 model was the adapter that unplugged
first in the earliest traces.

Link maximum on this host is 36000 Mb/s. The tunnelled USB3 grows to
14738 Mb/s when DP releases bandwidth.

Ruled out
---------

Each of these was tested; the trace signature stayed byte-for-byte
identical.

- Display firmware update (performed via macOS; now NVM 64.81)
- thunderbolt.clx=0 -- link low-power states
- thunderbolt.bw_alloc_mode=0 -- DP bandwidth allocation mode
- Thunderbolt/PCIe runtime PM (power/control=on on the NHI controllers,
  the tunnel PCIe ports and all TB devices). This did eliminate a
  separate, rarer failure in which the whole TB link dropped for ~8 s
  including USB -- but has no effect on the DP-only events described here.
- Cable: swapped the 2026 display's cable for the 2022 display's TB3
  cable. Link still negotiates generation 4 at 20 Gb/s x 2; failure
  unchanged.
- Bandwidth / link training: AUX dies outright (-ENXIO), no retrain is
  ever attempted.
- PSR / Panel Replay: "Sink support: PSR = no, Panel Replay = no".

Not yet tested: driving the 2026 display as two explicit tiles to mirror
the 2022 model's working configuration.

Questions
---------

1. Is the host expected to tear down both DP tunnels when one DP OUT
   adapter signals unplug, or could the teardown be scoped to the
   affected adapter?
2. Would a debounce or retry be appropriate before releasing the DP
   resource, given the adapter reappears ~2 s later?
3. Is the recurring "DPRX read timeout" on this device a known interop
   issue? dprx_timeout is at its default of 12000 ms here.

Happy to test patches or collect further traces.

Thanks,
Bernd Behler