eDP 1.5a低功耗显示链路：MSO分片、PSR/ALPM与HBR3调试避坑

简介：VESA Embedded DisplayPort（eDP）标准1.5a版面向嵌入式显示接口设计、笔记本与一体机平台开发、驱动适配及系统集成人员，给出基于DisplayPort 2.1的标准化显示面板接口规范，用于明确内部显示链路的需求、可选实现与集成约束，适合具备一定显示接口基础的硬件与驱动工程从业者查阅。压缩包内为1份PDF文档，整体约12.69MB，为无浮水印版本，正文从标准目的、适用范围与摘要切入，覆盖引言、背景、外部连接目标、文档组织、编写约定与优先级等模块，并附修订历史、知识产权声明及支持渠道等前置信息，便于按章节检索条款。已有772人学习下载。读者可从中获取eDP接口的功能定义、推荐选项、版本演进脉络和外部连接目标背景，为硬件方案评审、显示兼容性排查与平台化设计提供统一技术依据，也可作为理解嵌入式显示接口规范的长期参考资料。

1. 嵌入式显示接口里，最难的从来不是带宽

嵌入式显示接口最反直觉的一点是：它的技术难点不在于把带宽做高，而在于如何让链路在绝大多数时间里安静地待着。翻开 eDP 1.5a（2023 年 2 月发布，基于 DP 2.1 裁剪而来）会发现，MSO、ALPM、PSR1/PSR2、Panel Replay、Adaptive-Sync 这些机制占了大半篇幅，而链路速率到 8.1 Gbps/lane（HBR3）就封顶了。一条只跑几十厘米柔性板的内部链路，信道条件好到不需要更高的符号率，真正的对手是电池和唤醒延迟：屏幕常亮时每一毫瓦都要算账，唤醒慢一毫秒，用户就能看见闪一下或者一条撕裂。所以这份标准的骨架其实是一套「省电 + 快速唤醒」的协议设计，理解了它的状态机和握手顺序，你才明白为什么主控厂、面板厂和驱动工程师会在 PSR 状态机上反复拉扯。

2. MSO：一条主链路为什么被切成几条虚拟链路

Multi-SST Operation 是 eDP 里最容易被跳过、但在大尺寸高刷面板上又绕不开的一节。它的思路很朴素：物理上仍然是一条主链路（同样那几对差分线），逻辑上把它拆成 2 条或 4 条互相独立的 SST 链路，每条链路有自己的 lane 数、自己的链路训练、自己的时序发生器，各自驱动面板上的一段。这个设计不是为了提速，恰恰相反，它是为了让每一段跑得更慢。

面板的驱动 IC 有个像素率上限，这个上限跟工艺、良率、成本直接挂钩。一块 4K 高刷屏如果由一颗驱动 IC 全速吃下，那颗 IC 的像素时钟会顶到很难做的位置；拆成左右两段，每段只需要一半的像素率，用成熟工艺的低速驱动 IC 就能覆盖。所以 MSO 本质上是拿协议的复杂度，去换面板的良率和成本。

2.1 分片的三种基本配置：链路数 × 每链路 lane 数

标准里给出的配置组合不多，但每一种对应的物理含义完全不同：

关键点在于「每条链路独立训练」。链路训练是按 lane 分组的，MSO 下每条 SST 链路有自己的 CR_DONE/EQ_DONE 状态位、自己的电压摆幅与预加重设置、自己的 adjust request 反馈通道。这意味着一条链路上某个 lane 没训练好，不会连累另一条链路，源端可以做单链路重训而不是整条主链路复位——这个能力在实际调试里非常救命，因为整链复位通常意味着黑屏几百毫秒，而单链路重训最多是半屏闪一下。

还有一个常被忽略的细节：lane 到 segment 的映射是物理的，由板级布线决定，协议只负责声明「我把它当成 2 条还是 4 条链路」。如果硬件把 lane 0/1 接到左半屏、lane 2/3 接到右半屏，软件却按 4×1 配置，那么看起来「链路都训练成功了」，画面却是错的——这种错误在 CRC 校验里才会暴露出来。

2.2 拼接缝：MSO 的时序强制与像素重叠

把一个面板切成几段，最直接的后果是段与段之间会出现物理接缝。每段的接收端按自己收到的时序刷新，如果两段的帧起始时刻对不齐，接缝处就会出现一条随帧率抖动的横线或错位——这就是 MSO 必须定义时序强制（timing mandates）的原因。

标准要求各条链路的帧起始在时间上收敛到一个受控的偏移范围内，源端在配置 MSO 时必须保证这一点。常见的实现是先让各链路都进入稳定状态，再在一个统一的时刻下发帧起始对齐动作，而不是各自跑各自的时钟恢复。如果这条约束被违反，现象通常是接缝处一条细细的撕裂，静态画面看不出来，动态画面或者掉帧时出现，极其难查——因为它不像 CRC 错那样有明确的错误标志。

另一层问题是像素重叠：面板上相邻两段的驱动电路，在边界处理时可能需要邻段的像素数据。比如做 dithering、做局部过驱动补偿，或者为了视觉上的无缝拼接做边界融合，都需要边界几个像素的上下文。MSO 允许在段边界定义重叠像素区域，源端把边界像素重复发送给相邻段，两段的驱动各自拿到自己需要的上下文。重叠的像素数由面板规格和 DPCD 里的配置共同决定，配少了边界会出现亮度台阶，配多了纯粹浪费带宽。

2.3 DPCD 配置与逐链路 CRC：怎么确认每条链路没跑偏

MSO 的配置通过 DPCD 完成：链路数、每条链路的 lane 分配、重叠像素数、是否启用 MSO 模式，都在 sink 侧的能力字段和配置字段里体现。源端的顺序必须是先读能力字段，确认 sink 支持 MSO 以及支持哪种配置，再写配置并使能——反过来先写配置再读能力，是很多首次调试的翻车点，因为部分 sink 在未使能 MSO 时读出来的能力字段是默认值。

验证环节是 MSO 和普通 DP 最大的差别：普通 DP 的 CRC 是针对整帧的，而 MSO 下每条链路承载的画面内容不同，整帧 CRC 没有意义。标准为 MSO 定义了按链路的 CRC 寄存器，sink 在每帧结束时把该链路收到的像素数据算一遍 CRC 写入对应寄存器，源端对同一段像素范围独立算一遍，然后比对。

/* 伪代码：MSO 下逐链路 CRC 比对，寄存器名用功能别名表示，具体地址随版本变化 */ for (int i = 0; i < mso_link_count; i++) { uint32_t sink_crc, src_crc; /* Sink 在每帧收完后写入该链路的 CRC，注意要写 1 清除，否则读到的是上一帧的陈旧值 */ dpcd_read(aux, MSO_CRC_BASE + i * 4, &sink_crc, 4); /* 源端算的范围必须和该链路实际承载的范围一致，包含重叠区 */ src_crc = crc32_over_region(fb, seg[i].x_start - seg[i].ovl_left, seg[i].x_end + seg[i].ovl_right); if (sink_crc != src_crc) { /* 把链路号、像素区间、重叠像素数一起打出来，否则无法区分是布线错还是配置错 */ log_err("mso link %d crc mismatch: seg[%d,%d) ovl_l=%d ovl_r=%d", i, seg[i].x_start, seg[i].x_end, seg[i].ovl_left, seg[i].ovl_right); /* 单链路重训即可，不必复位整条主链路 */ mso_retrain_link(i); } dpcd_write(aux, MSO_CRC_BASE + i * 4, &clear_bit, 4); }

这段逻辑有三个容易写错的地方。第一是 CRC 的比对必须落在帧边界，帧中途去读，读到的是半帧的中间值。第二是清除动作，CRC 寄存器通常是写 1 清，不清就一直保持第一次错的值，导致后续每帧都报错，误判成持续故障。第三是像素范围要包含重叠区，如果源端算 CRC 时把重叠区裁掉，而 sink 把它算进去了，那么配置完全正确也会持续报错。

提示：MSO 下「所有链路都训练成功」不等于「画面正确」。链路层状态位只反映电气和通道对齐，视频内容是否正确必须靠逐链路 CRC 或肉眼比对接缝。

3. PSR 与 ALPM：静态画面下主链路关到什么程度

如果只能留一个机制来说明 eDP 的设计哲学，我会选 Panel Self Refresh。它的出发点极其朴素：用户盯着一个不动的画面看的时候，主链路为什么还要一帧一帧地把同样的数据再送一遍？这个问题的答案不是「因为要刷新」，而是「因为面板自己没有记忆」。PSR 就是把这份记忆给面板。

代价是面板里要多一块远程帧缓存和一套能自己跑时序的控制逻辑，这块成本最终会反映在面板报价上。所以 PSR 从诞生起就是分层的：PSR1 解决「整帧不变」的场景，PSR2 解决「大部分不变、局部在变」的场景，而后来引入的 Panel Replay 试图把这条路铺到没有完整自刷新能力的面板上。三层机制对应三档面板成本，这是理解整章的主线。

3.1 PSR1：主链路关掉之后，谁来刷这一帧

PSR1 的状态机可以粗略拆成四段：配置、进入、激活、退出。配置阶段源端读 sink 的 PSR 能力字段，确认它支持的版本、远程帧缓存的大小、支持的最大链路关闭时长等；进入阶段源端先确保当前这一帧已经完整送进 sink 的帧缓存，再通过主链路上的 VSC SDP 把「我要进 PSR」这件事告诉 sink，等 sink 的状态位确认之后就绪，才允许关掉主链路或者把它压到低功耗。

这里有个容易被忽略的约束：sink 的帧缓存是有限的，源端必须保证在缓存被读空之前完成「进入」的握手，否则面板会刷着刷着发现缓存里没数据了，出现一帧重复或者黑一下。标准里对进入前的等待、对 sink 侧链路关闭延迟的定义，本质上都是在给这段时序留余量。

进入之后，sink 用自己的时序发生器从远程帧缓存里读数据刷屏，主链路进入低功耗。此时源端并没有「关机」，它要维持对画面变化的检测——一旦有新内容，立刻发起退出。

3.2 退出的难点是帧时序重同步，不是唤醒本身

很多人以为 PSR 的难点在「怎么进去」，实际上真正让工程师掉头发的是「怎么出来」。原因很直接：在 PSR 激活期间，sink 已经切到自己的自由运行时序上，它的像素时钟相位、行场计数跟源端完全脱钩了。链路重新唤醒时，如果源端直接把新帧灌下去，两边时序相位不一致，屏幕上就会出现一帧错位、撕裂，或者更糟糕的一条横带。

标准为此定义了退出时的帧时序重同步流程：源端在恢复主链路后，不是立刻开始正常送帧，而是先经过一段约定的同步过程，让 sink 的时序重新锁定到源端的帧节奏上，然后再恢复正常视频。同步过程的长短、需要送几帧、sink 在这期间显示什么，都是有规定的。踩过这个坑的人通常会记住一个经验：退出序列里任何一步被「优化」掉，都会以偶发闪烁的形式回来找你，而且只在特定刷新率、特定温度下复现。

PSR 激活期间还允许「单帧更新」：源端发现画面变了，但只想更新一帧然后继续自刷新。这时它需要把链路唤醒、送一帧、再回到自刷新，整个来回的时序同样要走规定的路径，不能简化成「随便插一帧进去」。

3.3 PSR2：把整帧刷新拆成区域刷新

PSR2 的核心增量是选择性更新（Selective Update）。sink 的帧缓存不再是一个整体，而是被划分成可寻址的区域，源端每帧只需要把发生变化的区域连同位置信息送过去，sink 把这些区域贴回帧缓存，其余部分继续用缓存里的旧数据自刷新。

这对桌面场景的收益是巨大的：光标闪烁、时钟数字跳动、进度条走一格，这些变化只占屏幕的千分之几，PSR2 下主链路的占用时间可以降到接近零。但它的开销模型并不线性——每个选择性更新区域都要带位置、尺寸等描述信息，区域数量越多，描述开销越大。所以标准里对每帧的区域数量和最小尺寸都有约束，超出之后源端应该退回整帧更新，而不是硬塞。

/* 伪代码：把脏矩形合并成 PSR2 的选择性更新区域 */ #define SU_MAX_REGIONS 8 /* 上限来自 sink 的 DPCD 能力字段，不要写死 */ #define SU_GRAN_X 4 /* 水平对齐粒度，按 sink 要求向上取整 */ #define SU_MERGE_GAP 16 /* 两个区域间距小于此值时，合并比多发一个更划算 */ int su_build(const struct rect *dirty, int n, struct rect *out) { sort_by_area_desc(dirty, n); /* 大块优先，小块更容易被合并掉 */ int m = 0; for (int i = 0; i < n && m < SU_MAX_REGIONS; i++) { struct rect r = align_up(dirty[i], SU_GRAN_X); int merged = 0; for (int j = 0; j < m; j++) { if (rect_gap(out[j], r) < SU_MERGE_GAP) { out[j] = rect_union(out[j], r); merged = 1; break; } } if (!merged) out[m++] = r; } return m; /* 返回 0 表示「合并完还是太多」，由调用方回退整帧更新 */ }

这段合并逻辑的关键参数是合并阈值。阈值太小，区域数量迅速顶到上限，后面的脏矩形只能丢弃，导致画面残影；阈值太大，一个光标就能把半个屏幕圈进更新区域，选择性更新退化成整帧更新，白忙一场。工程上的做法是按分辨率和典型场景（文字编辑、视频播放、光标闪烁）各标定一组值，而不是全局一个常数。

对齐粒度同样不能省。sink 内部的缓存读写是按块组织的，源端送的区域没对齐，sink 要么拒绝，要么内部扩展到对齐边界——前者报错，后者让你算的带宽全错。所以align_up不是保守写法，而是必须。

3.4 ALPM：不用帧缓存，也能在帧间把链路放倒

PSR 需要面板有帧缓存，而 ALPM（Advanced Link Power Management）不需要。它利用的是帧与帧之间的空隙：即使在正常显示状态，行场消隐期间主链路也是空闲的，ALPM 允许链路在这些空隙里进入低功耗状态，下一帧开始前再唤醒。

标准定义了两种信令方式，这个二分法很能说明问题：

AUX-less 的坑集中在「唤醒期间不能碰 AUX」这一条上。源端驱动在链路低功耗时如果还习惯性地去读一下 DPCD 状态寄存器，就会把唤醒序列打断，表现为进入 ALPM 后偶发无法唤醒，或者唤醒后链路训练失败。正确的顺序是先退出 AUX-less 模式，再访问 DPCD；很多驱动框架的默认行为恰恰相反，因为它假设 DPCD 永远可读。

ALPM 与 PSR 是互补而非替代关系：PSR 管「画面不变」的长时段，ALPM 管「帧与帧之间」的短空隙。两者叠加时，退出路径会变长，所以标准对组合场景下的唤醒时长有额外约束，做低功耗预算时要把两段延迟加在一起算。

3.5 错误管理：CRC 不匹配时谁来兜底

自刷新期间，源端和 sink 之间没有连续的数据流，源端无从知道面板上显示的东西对不对。标准给的兜底手段是 CRC：sink 对收到的帧或区域算 CRC 回传，源端比对，不一致就强制走一次全帧更新。

这套机制的设计意图不是「修错」，而是「限错」。链路瞬时干扰导致的错像素，靠重传单帧解决不了根本问题，但可以让错误只停留在一帧里，而不是在自刷新的缓存里一直留存、越刷越花。所以错误恢复逻辑里有两条独立触发路径：CRC 不匹配，以及源端侧的超时计时器。后者是为了防「sink 已经挂了但状态位还挂着」的情况——只依赖对端上报的错误恢复机制，在对端死掉时会一起死。

4. 链路训练与电气预算：HBR3 的眼图怎么收敛

eDP 的电气章节读起来像一份射频文档，但它要回答的问题只有一个：在一条几十厘米、经过两三个连接器的柔性板上，怎么保证 8.1 Gbps/lane 的信号到接收端还能被正确采样。理解了参考点的定义，这一章的逻辑就通了。

4.1 TP1、TP2、TP3_EQ：眼图到底在哪测

这三个测试点不是随便起的名字。TP1 在源端引脚，TP2 在链路中段（通常对应连接器或测试夹具），TP3 在接收端引脚。按常理，眼图应该在最差的 TP3 测，但内部链路的损耗和连接器反射会让 TP3 的眼图闭合得很难看，如果直接按 TP3 定义模板，几乎所有的面板线都过不了。

eDP 的做法是在接收机前面放一个标准化的参考均衡器，测试点变成 TP3_EQ——也就是「经过参考均衡器之后」的眼图。这等价于承认一个现实：接收端本来就有均衡能力，测试应该衡量「均衡之后还剩多少余量」，而不是「均衡之前有多糟」。这个定义直接决定了链路预算怎么分配：源端负责摆幅和预加重（TP1 的差分电压、TP2 的预加重档位），接收端负责均衡，中间的柔性板和连接器只要在约定的损耗范围内就行。

标准里附带了一张差分电压训练表（VDIFF training table），把摆幅、预加重档位和对应的电压值列出来，供源端在训练时逐档尝试。这张表是 informative 的，意味着具体取值可以按实际链路调整，但档位的语义是固定的——否则不同厂家的源端和 sink 无法用同一套 adjust request 协议对话。

4.2 抖动预算为什么在 5.4 Gbps 处切开

单位间隔（UI）随时钟速率下降而缩短：1.62 Gbps 对应约 617 ps，2.7 Gbps 约 370 ps，5.4 Gbps 约 185 ps，8.1 Gbps 只剩约 123 ps。抖动源里有一部分是绝对值（PLL 的本底抖动、电源噪声耦合、串扰），它不随 UI 缩短而变小。所以当 UI 从 185 ps 掉到 123 ps，同样的绝对抖动占比从百分之几跳到百分之十几，原来的预算分配方式就失效了。

标准因此把抖动与噪声预算在 5.4 Gbps 处切成两段：HBR2 及以下用一套预算，HBR3 用另一套，并且对源端的发送参数（eDPTX 参数）给出不同约束。这不是为了把文档写长，而是因为在这条分界线上下，失效模式从「幅度不够」变成了「时序余量不够」，排查手段也完全不同——前者看摆幅和预加重，后者必须看眼图闭合度和参考均衡器的效果。

注意：在 HBR3 上调链路时，如果沿用 HBR2 的眼图模板去评估，会得到「怎么调都过不了」的结论。模板必须换成 TP3_EQ 对应的那一套，否则所有优化都是白费力气。

4.3 链路训练的收敛过程与快速训练

链路训练分两个阶段：时钟恢复（CR）保证接收端能正确提取时钟，通道均衡（EQ）保证数据模式能被正确判决。每个阶段完成后对应 lane 的状态位置起，源端读 adjust request 得知接收端要求加大摆幅还是加强预加重，逐轮调整，直到两条状态位都置起或者超过重试上限。

eDP 在这个流程上加了一个很实用的东西：如果 sink 支持、且源端保存了上次训练成功的摆幅/预加重组合，可以跳过完整的握手，直接把缓存的设置下发，然后在很短时间内确认状态位。这就是「快速训练」，它存在的唯一理由是唤醒延迟——从 ALPM 或 PSR 退出的时间预算通常是毫秒级，完整训练走一遍根本来不及。

/* 伪代码：先试快速训练，失败再退回完整流程，并作废缓存 */ int edp_link_train(struct edp_link *lk) { if (lk->cached_vdiff_valid && sink_supports_fast_training(lk)) { /* 直接下发上次成功的 swing/pre-emphasis，省掉逐轮 adjust 的往返 */ dpcd_write(lk->aux, DPCD_LANE0_SET, lk->cached_vdiff, lk->lane_count); if (wait_status(lk, CR_DONE | EQ_DONE, 10 /* ms，具体值由 sink 能力字段给出 */)) return 0; /* 快训失败不要硬扛：链路可能换了、温度变了、面板换批次了 */ lk->cached_vdiff_valid = false; } /* 完整训练：CR 阶段逐 lane 收敛，再进 EQ 阶段 */ for (int attempt = 0; attempt < MAX_TRAIN_ATTEMPTS; attempt++) { if (train_clock_recovery(lk) && train_equalization(lk)) { cache_vdiff(lk); /* 成功后缓存，供下次快训使用 */ return 0; } downgrade_link_rate_or_lanes(lk); /* 降速/减 lane 是最后手段，要记日志 */ } return -EIO; }

两个参数值得多说。一是快训的等待窗口：给太短，本来能成功的快训被判失败，白白多走一遍完整训练，唤醒变慢；给太长，链路真的失效时也要等满才降级，用户看到的是黑屏时间变长。这个值应该从 sink 的能力字段读，而不是拍一个常数。二是重试上限与降级策略：训练反复失败时降速或减 lane 能救回大部分板子，但降级必须打日志，否则你会得到一块「能亮但分辨率不对」的屏，而且没人知道为什么。

4.4 AUX_CH 与 LV-HPD：两条不起眼但决定成败的边带

AUX 通道跑在 1 Mbps 量级，负责 DPCD 读写、链路训练的 adjust request、以及 PSR/ALPM 的状态握手。速率不高，但它是所有控制面逻辑的地基，AUX 一错，上层全部玄学。标准里对 AUX 的电气子块和拓扑有单独定义，包括走线、终端、以及在长柔性板上的信号完整性要求。

HPD 在 eDP 里用的是低电压版本（LV-HPD），电平比外部 DP 的 3.3V 低。这个改动的动机很实际：内部链路的两端都在同一个机箱里，做电平转换的器件和功耗都是纯开销，把电平降下来可以直接对接 SoC 的 IO，省掉一级转换。代价是抗噪余量变小，HPD 走线如果和背光升压、天线走线并行，就容易出现莫名其妙的「面板掉了又回来」。

AUX 还有一个常被忽略的用途：多点触控数据可以走 AUX 通道回传，而不占用主链路带宽。这让触控和显示共用同一组连线成为可能，对超薄设备很有价值——但也意味着触控数据会和 DPCD 访问竞争同一条低速通道，时序设计上要给触控留出窗口。

5. 避坑排查：eDP 调试里那些看起来像玄学的现象

这一节记录的是四类在现场反复出现的问题。它们的共同点是：现象看起来像硬件坏了，实际原因往往在状态机的某个顺序上。

5.1 PSR 进得去出不来，退出瞬间一条横带

现象：静态画面停留几秒后链路正常进入低功耗，动一下鼠标，屏幕恢复的瞬间出现一条水平亮带或错位，随后正常。降低刷新率或提高温度时更容易复现。

原因：退出时的帧时序重同步没走完整。sink 在自刷新期间用自己的自由运行时序刷屏，源端恢复主链路后直接灌新帧，两边相位不一致，第一帧的部分行被写到了错误的位置。很多驱动为了缩短唤醒延迟，把「等待 sink 确认退出完成」这一步做成了异步，导致同步过程被压缩。

解决：严格按标准的退出序列执行，源端在恢复链路后必须等到 sink 的重同步完成状态位，再开始送正常视频帧；不要在垂直消隐中途切换，切换点要落在帧边界。如果延迟预算紧张，优化方向应该是缩短链路训练（用快速训练），而不是砍掉同步步骤。

5.2 AUX-less 模式下进入后再也唤醒不了

现象：启用 AUX-less ALPM 后，设备在空闲一段时间后黑屏，按键无响应，只有断电重启才能恢复。日志里看不到任何错误，因为出错时根本没机会打印。

原因：唤醒期间禁止 AUX 事务，但驱动框架里有定时轮询 DPCD 的逻辑（比如周期性读 sink 状态、读链路状态做健康检查）。这条轮询在 AUX-less 期间打断了唤醒序列，sink 停在中间状态等不到后续的模式，源端则在等状态位，双方互相等。

解决：进入 AUX-less 之前必须停掉所有 DPCD 轮询，并把「当前处于 AUX-less」做成一个全局可见的状态，任何要访问 DPCD 的路径先检查它。唤醒序列里第一步是退出 AUX-less 模式，之后才允许 DPCD 访问。如果框架改造代价太大，退一步改用 AUX-wake，用一点静态功耗换稳定性。

5.3 MSO 四段拼接，接缝处固定一条竖线

现象：4×1 配置下，画面在固定的 x 坐标上有一条一像素宽的竖线，颜色偏暗或偏亮，静态动态都在，CRC 不报错。

原因：重叠像素配置和面板实际的分段边界不一致。源端按配置算了重叠区并重复发送了边界像素，但面板实际的分段起点比配置值偏移了几个像素，导致某一段的最外侧一列拿到了错误的邻居数据。CRC 只覆盖各段自己的像素范围，重复发送的那部分不在校验范围内，所以查不出来。

解决：对照面板规格书核对每段的起始像素和重叠像素数，注意有些面板的重叠是单边的（只有左边界需要邻段数据），配成双边会多送一列。验证手段是让屏幕显示纯色渐变，接缝处的亮度台阶会非常明显；也可以用逐段 CRC 加上边界列的单独校验来定位。

5.4 HBR3 眼图怎么调都过不了，降到 HBR2 就正常

现象：同一块板子，HBR2 下链路训练一次通过，切到 HBR3 后训练反复重试，偶尔能成功但跑一段时间会掉链路。加大预加重、加大摆幅都没有明显改善。

原因：用了错误的眼图模板。HBR3 必须在 TP3_EQ（经过参考均衡器之后）评估，如果仍按 HBR2 那套在 TP3 考核，模板本身就过于严苛，怎么调都过不了。另一种情况是柔性板和连接器的损耗超出预算，参考均衡器补不回来，此时的现象和模板错误很像。

解决：先把测试点切到 TP3_EQ，确认模板选对；仍然不过时，用矢量网络分析仪量一下柔性板加连接器的插损，和标准给的损耗预算对一下。如果确实超了，优先改连接器和走线，而不是继续在源端参数上打转——预加重只能补偿高频衰减，补不了反射。

6. 设计取舍：eDP 为什么在很多地方选择「够用就好」

把整份标准读完，你会发现 eDP 1.5a 有一致的价值取向：内部链路的瓶颈是功耗和唤醒延迟，不是峰值带宽。这条主线解释了几乎所有的「保守」选择。

链路速率封顶在 HBR3 就是最典型的一处。外部 DP 一路往更高的符号率走，是为了支撑长线缆、高分辨率、多显示器；而 eDP 的「线缆」是几十厘米的柔性板，信道好、损耗可控，再往上提速的代价是编解码复杂度、功耗和 EMI，收益却很小。真正的带宽压力被交给了 DSC——用压缩换带宽，比用符号率换带宽在功耗上划算得多。这是一个明确的取舍：宁可让压缩算法承担复杂度，也不让物理层承担功耗。

PSR 的三层设计（PSR1 / PSR2 / Panel Replay）同样是在做成本分层。面板里加一块远程帧缓存和多一套时序发生器是实打实的成本，不是每块屏都愿意付。PSR1 只要求「整帧不变时自刷新」，PSR2 要求缓存可寻址以支持区域更新，Panel Replay 则把「面板能自己刷新」这个前提放宽，让更多面板能享受「只在变化时传输」的收益。三档能力由 DPCD 报告，源端按能力降级使用——这套模式的好处是同一份驱动能覆盖从低端到高端的所有面板，坏处是驱动里必须维护一个能力矩阵，任何一处漏判都会变成「某款机型上 PSR 不生效」的疑难杂症。

ALPM 定义两套信令（AUX-wake / AUX-less）也是同一个逻辑：省掉 AUX 时钟域能拿到更低的静态功耗，但状态机更难做对，所以标准两套都留着，让厂家按自己的功耗预算和验证能力选。

验证上我的习惯是三条线交叉，缺一条都不算验证过。第一条是状态机 trace，把 PSR/ALPM 的每次进入退出、每次链路训练、每次 CRC 不匹配都打上时间戳，出问题时先看时序而不是先猜硬件。第二条是逐链路 CRC 和帧 CRC，它能把「画面看起来正常」变成「数据确实正确」。第三条是眼图和插损，链路层的错误最终都要回到电气上找原因。三者的关系是：CRC 报错告诉你有问题，状态机 trace 告诉你问题出在哪个阶段，眼图告诉你根因在物理层还是协议层。

最后一条血泪经验：任何一次「为了省几毫秒而简化退出序列」的改动，都要单独跑一遍低温、低刷新率、以及背光亮度突变的组合场景。PSR 和 ALPM 的 bug 有极强的场景依赖性，常温常压下的实验室里跑一天都复现不了，用户在地铁上两分钟就能撞见。从那以后我每次改低功耗相关的状态机，都强制走一遍这三条线加三个场景的组合，宁可多花两天，也不要在发布后追一个偶发闪屏。希望帮到你。

这份 eDP 1.5a 的 PDF 是干净的版本，没有叠加水印，目录层级完整到每个小节，从 MSO 的分段配置到 PSR 的退出时序都能直接翻到对应页码，配合上面提到的状态机和电气两条

本文还有配套的精品资源，点击获取