Speaker
Description
A familiar failure motivates this talk: two high-resolution displays on one USB4/Thunderbolt dock, each working alone but not together, because nothing arbitrates the shared link.
A DisplayPort monitor on such a dock looks like an ordinary connector to userspace, but in the kernel the work is split across two subsystems that never call each other. The graphics driver (i915/xe plus the DRM DP tunnel helpers) owns the DP source, mode validation, and atomic state. The USB4/Thunderbolt connection manager (drivers/thunderbolt, or controller firmware) owns the physical link and the bandwidth of every tunnel (i.e. DisplayPort, PCIe, USB3) sharing it. The two domains coordinate only through the DisplayPort Bandwidth Allocation protocol: a small set of DPCD registers carried over AUX.
From that starting point the full bandwidth lifecycle unfolds: how available bandwidth is estimated, how a stream's requirement is computed, how the group budget is enforced during the atomic check, how the request is issued at commit and answered by the connection manager, and how the state is updated at runtime.
Overview
Outline
- DP over USB4/Thunderbolt, and the subsystem split
- What DP tunneling is, and how it appears to userspace.
- The split of responsibility: DRM/KMS vs.
drivers/thunderbolt. - The Bandwidth Allocation protocol
- The DPCD register interface and how a request reaches the connection manager.
- How the DRM DP tunnel helpers bridge the two domains.
- Case study: two displays on one dock
- Walkthrough of a dock bandwidth exhaustion scenario.
- Estimation, requests, and atomic-state representation in
i915/xe. - Hotplug
- Dynamic recalculation on hotplug and state changes.
- Future work and upstreaming
- Panel Replay bandwidth optimization.
- Asymmetric USB4 links and UHBR.
- Validation strategies.
Upstream contributor : Imre Deak imre.deak@intel.com
| In-person or virtual presentation | Virtual |
|---|---|
| Code of Conduct | Yes |
| GSoC, EVoC or Outreachy | No |
