📚 课程目录第3章 ASPM进入条件

3. ASPM 进入条件：空闲检测、延迟容忍、软件触发机制

ASPM 不是随便就能切进去的。你得满足三个硬条件：链路空闲、延迟容忍、软件允许。缺一个，节能模式就进不去。

我当年调试一块 PCIe 3.0 的 SSD，ASPM 死活进不去。链路已经没流量了，功耗就是降不下来。后来发现是驱动里没设置延迟容忍——这玩意儿藏得挺深，但坑也最大。

链路空闲检测是 ASPM 的敲门砖。说白了，物理层要确认发送和接收两条通路都闲着。

这里有个细节：L0s 进入只需要一个方向空闲，而 L1 必须双向空闲。我见过不少设计只检查了 TX 方向，RX 还在忙，结果 L1 永远进不去。嗯，你想想看，这得浪费多少电？

  关键参数： 空闲超时阈值——L0s 默认是 7 μs，L1 可以配置（通过 L1 Substates 能力寄存器）。实测时记得拿示波器抓 EI 序列，别光靠软件读数。

链路空闲了，但能不能切到低功耗状态，还得看系统能忍多久的唤醒延迟。这个机制由 延迟容忍报告（Latency Tolerance Reporting，LTR） 管理。

每个 Function（比如网卡、NVMe 控制器）告诉 Root Complex：“我最多能等 XX 纳秒，你超过这个时间我就不干了。” Root Complex 再结合所有设备的需求，决定是否允许 ASPM 进入 L1。

概念	说明	典型值（我见过的）
Service Latency	设备愿意等待的最长时间，超过后性能不可接受	10 μs ~ 10 ms（取决于场景）
Snoop / Non-Snoop 区别	Snoop 事务延迟要求更严，Non-Snoop 可以放宽	Snoop: 50 μs; Non-Snoop: 2 ms
LTR 消息	软件通过 Vendor Defined Message 下发延迟值	每 1 μs 粒度，最大可达 20 ms

我踩过最深的坑是：设备上报的 LTR 值小于实际唤醒时间。一块网卡报延迟容忍 100 μs，实际唤醒却要 500 μs。结果呢？丢包！宿主机的 TCP 重传直接爆炸。

注意： 测试 LTR 一致性时，必须验证设备报告的延迟容忍是否真实可靠。用协议分析仪抓 LTR 消息，然后实测唤醒时间，两件事缺一不可。

最后一步是软件点头。ASPM 的开启和关闭，最终靠 PCIe 配置空间的 Link Control Register 里的 ASPM Control 字段（bits 1:0）。

驱动或者 BIOS 会在枚举阶段设置这个字段。你以为这就完了？不，还有两个坑：

软件确认需要 Hardware Autonomous ASPM Enable 配合：某些平台支持 BIOS 自动配置，但驱动覆盖后会冲突。
L1.1 / L1.2 需要额外使能：L1 Substates 控制寄存器里还有 ClkReqEnable / L1_2Enable 等位，软件不写的话，L1 只能做到最浅的 L1。

我个人习惯，在测试脚本里第一步就是读 Link Control 2 和 L1 Substates Capability，确认所有使能位都对了。否则查半天找不到原因，白白浪费时间。

实操技巧： 用 lspci -vvv 看 Linux 下 ASPM 状态（LnkCtl: ASPM L0s/L1），用 setpci 可以手动修改使能位，但别忘了还要设置 LTR。我经常在验证环节写一个 shell 脚本，自动轮询这三个条件——空闲、延迟、软件开关。

三个条件不是独立的，它们按顺序触发：
空闲检测满足 → 向软件发中断（如果使能了） → 软件检查 LTR（或由硬件自动判断） → 最终切到 L0s/L1。

你看，链路空闲是前提，延迟容忍决定能不能睡，软件给最后的许可证。我画了一张图帮你理清关系：

说到底，验证这三个条件，最怕的就是“假满足”。我给你列个检查清单：

空闲检测：用协议分析仪确认 EI 序列持续 不小于 7 μs（L0s）或 不小于 2 μs（L1 要求更短，但 L0s 通常更长）。
我曾经发现某桥芯片的空闲检测器忘了看接收端，导致 L1 切进去以后根本没法唤醒——嗯，后来补了 errata。
延迟容忍：抓 LTR 消息，对比设备数据手册的唤醒时间。
我习惯在测试环境里故意注入一个超长延迟，看设备会不会丢失 pending 事务。
软件触发：反复写/读 Link Control 寄存器，确认 ASPM Control 位不会被硬件意外清零。
有些原生热插拔控制器会在复位后偷偷把 ASPM 禁用掉，驱动得重新使能。

最后啰嗦一句：这些条件你可能在仿真环境里都验过，但板级测试更棘手。信号质量差会导致误判空闲，LTR 消息可能被 DMA 干扰掉。你想想看，这些坑我哪一个没踩过？