RTR提供了一种可选机制，用于描述设备或功能进入准备状态所需的时间。在指示的情况下，允许软件在等待此功能中公告的时间后向设备或功能发出请求，并且无需等待其他地方所需的（更长）时间。
软件允许在最早的时间发出请求
- 接收到Readiness Notifications message
- 等待本文档或PCI,PCI-PM中指定的时间后
- 等待此功能的关联字段中指示的时间
- 等待系统软件或硬件定义的时间
只要以相同方式运行的同一设备没有更改，软件就可以缓存此功能的值，并使用这些缓存的值。
允许在所有Function中实现此功能。
如果出现以下情况，Function必须已准备就绪
- Immediate Readiness bit 清除，并且传统方式复位后，至少经过了 Reset Time 。
- 如果 Immediate Readiness bit = 1，Reset Time不起作用。
- 如果是USP的function，在与该function上游的dsp的数据链路层报告DL link active后，至少经过了DL_UP time。
- 如果Function支持FLR,在FLR有效后，至少经过了FLR Time。
- Immediate_Readiness_on_Return_to_D0 清除，Function从D3hot状态跳转到D0后至少D3hot to D0 Time。
-
如果Immediate_Readiness_on_Return_to_D0 =1 ，D3hot to D0 Time不起作用
-
当Immediate_Readiness_on_Return_to_D0 清除，Function从D3hot状态跳转到D0后至少 D0 Time后，Function必须准备就绪。此外，Function必须处于D0 uninitialized 或者D0 active状态，取决于 No_Soft_Reset bit的值。
对VF而言，额外的行为定义在Ch9。
如果上述条件不适用，则Function的行为不由RTR功能去诶多功能，必须按照其他地方定义的方式做出响应（包括，例如 无响应或者具有配置状态的响应）。
报告的时间值由特定于实现的机制确定。此功能中定义了valid位，以允许设备推迟报告时间值，例如允许通过基于驱动程序的机制进行硬件初始化。如果有效位保持清除并且设备驱动程序启动后已过1分钟，则允许软件假设不会报告任何值。即需要设备拉高valid，向软件报告延时值。如果过了一分钟都没有这个操作，软件就认为设备不会再报告了。
寄存器字段是浮点数，高3bit是缩放因子，低9bit是值：
RTR功能结构体：
比如A1Eh = 101 0 0001 1110b。101b代表33ms，1e是30，所以延时约为1s。
不允许配置该值超过1分钟。
7.9.17.1 Readiness Time Reporting Extended Capability Header (Offset 00h)
Capability ID = 0022h。
7.9.17.2 Readiness Time Reporting 1 Register (Offset 04h)
reset time：传统复位以后，过了这么长时间，Function必须准备就绪。 Immediate Readiness （status寄存器04h的bit16）=0的时候，reset time不起作用。valid在bit31，valid为0的时候，所有time都不起作用。
DL_Up time： Function上游的数据链路层报告Link Active后，过了这么长时间，Fucntion必须准备就绪。
valid：等于1，表示time设置有意义。
这三个字段都是HwInit的。时间值可能取决于设备配置。设备特定机制（可能涉及设备驱动程序）可能参与确定时间值。valid是否配置，time设置为多少都是设备特定实现的。
7.9.17.3 Readiness Time Reporting 2 Register (Offset 08h)
和上面的2个time一样。前文已经解释过了。
FLR 是 FLR复位后这么长时间，设备必须就绪。
D3 hot to D0 time 是设备从D3hot跳转到D0后经过这么长时间，设备必须就绪。
这些time都必须小于1分钟。
综上，RTR的功能是告诉软件，该设备复位后，多长时间就能准备好，不需要额外等。或者设备有不同的模块，在不同的配置后，再复位，设备准备就绪的时间是不一致的。
