PCIe RN（Readiness Notification）介绍

Background

RN

Readiness Notification（RN）旨在缩短PCIe Device/Function启动或复位之后到软件可以发送Cfg TLP之间的等待时间。RN通知机制包括DRS（Device Readiness Status）和FRS（Function Readiness Status）两种事件，该机制直接标志Device/Function进入到Configuration-Ready状态。

• 启用RN机制后，可以提供比CRS机制更迅速的启动时间，后者则需要等待长达1s的polling。

• PCIe协议建议在实现过程中，FW/SW/HW减少一切不必要的延迟，充分利用RN机制来决定所需要的延迟。

• Configuration-Ready：Function能够收到配置请求，并回复带有Success状态的Completion，则该Function为Configuration-Ready状态。

其主要流程如下图：

• 设备发送DRS消息，此时设备还没有分配Bus号，所以Host并不能根据RequesterID确认Configuration-Ready的设备。但是该设备对接的Switch下游端口会置DRS Message Revieved为高，Host在枚举过程中可以通过该位域确认下游设备是否Ready

• Function在Configuration-Ready之后发送FRS消息，RC中的FRS Queue记录消息的RequesterID和Reason，Host通过该队列可以确认下挂Function是否Ready

DRS

DRS表示Device进入了Configuration-Ready状态，以下为触发DRS事件的条件：

• Exit from Cold Reset

• Exit from Warm Reset, Hot Reset, Loopback, or Disabled

• Exit from L2/L3 Ready

• Any other scenario where the Port transitions from DL_Down to DL_Up status.

DRS消息协议遵守以下规则：

• DRS没有开关机制，只是在Link Capabilities2寄存器有DRS Supported位域。支持DRS的DSP，该位域必须为1；支持DRS的USP，该位域建议配置为1，即使该位域为0，USP也允许发送DRS message。

• 当DL_Down变为DL_Up，且该USP下挂的Logical Bus内所有non-VF都Ready之后，才能发送DRS消息。对于Type0 Function以及非switch USP的Type1 Function，他自己是Configuration-Ready就代表该Function Ready了；对于switch USP的Type1 Function，需要他自己以及其下挂secondary bus上的Function都Configuration-Ready之后，该Function才Ready。

• Device发出DRS消息后，除非发生了DRS事件，否则跟该DRS对应的Configuration-Ready的非VF Function不应返回CRS Completion消息。

• 实现了DRS的switch，所有端口都应支持DRS机制。对switch DSP下游的Device而言，switch发出的DRS消息并不意味着这些Device Ready了，这些Device是否Ready是独立于switch的。

• Switch DSP及RP中需实现DRS Message Received Bit，以指示其接收到了DRS消息。

• Function在未分配BDF号时发出DRS消息是合法的，此时DRS消息Requester ID中的Bus Number为0。若此时Switch下行端口开启了ACS来源验证，该消息有可能会触发ACS报错。

DRS消息采用Vender-Defied-Mechanism机制，发送不带payload的Type1 Message：

FRS

FRS代表Function进入Configuration-Ready状态，FRS事件触发条件为：

• Function Level Reset (FLR)

• Completion of D3Hot to D0 transition

• Setting or Clearing of VF Enable in a PF (SR-IOV）

FRS消息遵守以下规则：

• Requester ID指示Readiness发生变化的Function

• Reason字段表明Readiness变化的原因

• Function发出FRS消息后，除非发生了DRS/FRS事件，否则该Function不应返回CRS Completion消息

• 实现了FRS的switch，所有端口都应支持FRS机制，且其USP需要能够发送FRS消息

• PF需要在VF enable/disable流程结束后发送FRS消息

• RP和RC中需要实现FRS Queuing Extended Capability

FRS消息采用Vender-Defied-Mechanism机制，发送不带payload的Type1 Message：

FRS Queuing

FRS Queue就是用于记录RC或RP收到的FRS消息的：

• Reset，DL_Down之后FRS Queue为空

• 只要FRS Queue非满，FRS消息就要按接收顺序入队，FRS Message Received bit置1并产生中断；当FRS Queue满后，新的FRS消息丢弃，已经入队的消息保留， FRS Message Overflow bit 置1并产生中断

• FRS Message Queue Register中展现的是最早的FRS消息，向该寄存器写任何数据，该FRS消息出队，下一个FRS消息展现在FRS Message Queue Register中，该寄存器为0代表队列为空

• 实现 FRS Queueing Extended Capability的Function也必须实现MSI/MSI-X

Readiness Time Reporting Extended Capability

同时PCIe还提供了Readiness Time Reporting能力用于设备告诉软件Device或者Function Configuration-Ready的时间，软件需要在等待这个时间之后才去进行配置的读写。

Software is permitted to issue requests upon the earliest of:

• Receiving a Readiness Notifications message

• Waiting the appropriate time as specified in this document or in specifications including the [PCI] and the [PCI-PM].

• Waiting the time indicated in the associated field of this capability.

• Waiting for the time defined by system software or firmware