Latency Tolerance Reporting and Optimized Buffer Flush/Fill for power efficiency
LTR (Latency Tolerance Reporting) allows endpoints to report their latency requirements to the platform. This enables the platform to make informed power management decisions while meeting device latency needs.
Device Platform Power Manager
│ │
│ LTR Message │
│ "I can tolerate 100μs │
│ snoop latency" │
│ ─────────────────────────────►│
│ │
│ Platform decides:
│ - Can enter C6 state (90μs exit)
│ - Cannot enter C7 (150μs exit)
│ │
│ Traffic resumes within │
│ 100μs of wake │
│ ◄─────────────────────────────│
Deep power states (C6, C7, package C-states) save significant power but have long exit latencies. LTR lets the platform safely enter these states when devices can tolerate the latency.
| C-State | Power Savings | Exit Latency |
|---|---|---|
| C0 (Active) | None | 0 μs |
| C1 | Low | ~2 μs |
| C3 | Medium | ~50 μs |
| C6 | High | ~100 μs |
| C7 | Very High | ~150 μs |
| Package C6 | Maximum | ~200+ μs |
LTR Message (routed to Root Complex):
Header (3 DW):
┌─────────────────────────────────────────────────────────────────┐
│ Fmt=00 │ Type=10000 │ Routing=000 │ ... │ Length=1 │
│ │ (Msg) │ (to RC) │ │ │
└─────────────────────────────────────────────────────────────────┘
Payload (1 DW):
┌─────────────────────────────────────────────────────────────────┐
│ Rsvd │ No-Snoop │ Snoop Lat │ No-Snoop │ Snoop Lat Scale │
│ [31:26]│ Req [25]│ Value[24:16]│ Scale[15:13]│ Value[9:0] │
└─────────────────────────────────────────────────────────────────┘
Scale Values:
000 = 1 ns
001 = 32 ns
010 = 1024 ns (1.024 μs)
011 = 32768 ns (~33 μs)
100 = 1048576 ns (~1 ms)
101 = 33554432 ns (~34 ms)
| Bit | Field | Description |
|---|---|---|
| 11 | LTR Mechanism Supported | Device supports LTR |
| Bit | Field | Description |
|---|---|---|
| 10 | LTR Mechanism Enable | Enable LTR messaging |
| Offset | Register | Description |
|---|---|---|
| 00h | Extended Cap Header | ID = 0018h |
| 04h | Max Snoop Latency | Maximum tolerable snoop latency |
| 06h | Max No-Snoop Latency | Maximum tolerable no-snoop latency |
OBFF (Optimized Buffer Flush/Fill) allows the platform to signal devices when the CPU is in a low-power state, enabling devices to optimize their memory access patterns.
Platform Device
│ │
│ CPU entering deep sleep │
│ │
│ ─── OBFF Signal (CPU_IDLE) ─────►│
│ │
│ Device defers
│ non-urgent DMA
│ │
│ CPU waking up │
│ │
│ ─── OBFF Signal (CPU_ACTIVE) ───►│
│ │
│ Device resumes
│ normal DMA
| Method | Description | Speed |
|---|---|---|
| Message | OBFF Message TLP from RC | In-band |
| WAKE# Signaling | Sideband WAKE# pin encoding | Fast (out-of-band) |
| State | Meaning | Device Action |
|---|---|---|
| Idle | CPU in low-power state | Defer non-urgent DMA |
| Active | CPU active | Normal operation |
| OBFF | Optimized flush/fill window | Good time for buffer operations |
| Bits | Field | Description |
|---|---|---|
| 19:18 | OBFF Supported | 00=Not, 01=Message, 10=WAKE#, 11=Both |
| Bits | Field | Description |
|---|---|---|
| 14:13 | OBFF Enable | 00=Disabled, 01=Message, 10=WAKE# |
LTR tells platform: "I can wait X microseconds"
OBFF tells device: "CPU is idle/active right now"
Together they enable:
1. Platform enters deep C-state (based on LTR)
2. Device notified via OBFF (CPU_IDLE)
3. Device buffers data instead of immediate DMA
4. CPU wakes, OBFF signals CPU_ACTIVE
5. Device performs batched DMA efficiently
Result: Deeper power states + efficient I/O batching
lspci -vv | grep LTR - Check LTR status/sys/devices/.../power/ - Power management sysfsProper LTR/OBFF configuration can reduce platform power by 10-30% during idle periods while maintaining acceptable latency.