现象:
- 速率达到Gen5进行Equalization,但是Gen5的Equalization没有成功
- 掉速到GEN4但是两边都协商上,继续掉速到GEN1
- 掉速到GEN1但是两边都没协商上,进入detect状态
- 重新进行Detect-polling-configuration交互协商过程
理论分析:
- Equalization时间:
每个Phase都有固定要求时间,Host phase 1 超时时间是24ms
Device phase 1 的超时时间12ms
数据分析和解决:
- 首先看device侧:
- device phase 0 超时导致掉速到Gen4,查看下超时时间是11.58ms
所以按照以下的时间计算,从EP 开始Phase0 TS1到掉速EIOS标志点
B: Gen4 .Recovery.Lock 状态,持续时间抓出来是21.3ms,按照协议是24ms
C. 最后Gen4直接掉速到Gen1进行Recovery.lock状态,也是持续了24ms时间 (这里是否需要掉速到Gen3不是很确定)
D. Gen1超时后进入Detect-Polling状态
2. Host端:
a. Host端从Phase 1 开始,持续了24ms,超时掉速到Gen4
b. 进入Gen4.Recovery.lock状态,持续了20ms
按照协议是24ms(也见过持续48ms的Host)
c.掉速到Gen1.Recovery.lock状态,
d. Gen1超时后进入Detect-Polling状态
3. 所以Host端和Device端都是一样的流程,Gen5-Gen4-Gen1
问题点:为啥两边在Gen4和Gen1都没有协商锁住,稳定在Gen4或者Gen1速率的L0状态
两边没有协商上:
- 总结来讲,这次掉速没有在Gen4协商上,是由于Host端导致,Phase1 协商失败后长时间停留在EI状态没有exit出来,导致和Device侧没有在Gen4协商上