On Mon, Jan 06, 2025 at 03:03:04PM +0530, Krishna Chaitanya Chundru wrote:
> Some controllers and endpoints provide provision to program the entry
> delays of L0s & L1 which will allow the link to enter L0s & L1 more
> aggressively to save power.
Although these are sort of related because FTS is used during L0s->L1
transitions, I think these are subtle enough that it's worth splitting
this into two patches.
> As per PCIe spec 6 sec 4.2.5.6, the number of Fast Training Sequence (FTS)
> can be programmed by the controllers or endpoints that is used for bit and
> Symbol lock when transitioning from L0s to L0 based upon the PCIe data rate
> FTS value can vary. So define a array for each data rate for nfts.
>
> These values needs to be programmed before link training.
IIUC, the point of this is to program the N_FTS value ("number of Fast
Training Sequences required by the Receiver" as described in PCIe
r6.0, sec 4.2.5.1, tables 4-25, 4-26, 4-27 for TS1, TS2, and Modified
TS1/TS2 Ordered Sets).
During Link training, all PCIe components transmit the N_FTS value
they require. Sec 4.2.5.6 only describes the Fast Training Sequence
from a protocol perspective. The fact that the N_FTS value of a
device may be programmable is device-specific.
Possible text:
Per PCIe r6.0, sec 4.2.5.1, during Link training, a PCIe component
captures the N_FTS value it receives. Per 4.2.5.6, when
transitioning the Link from L0s to L0, it must transmit N_FTS Fast
Training Sequences to enable the receiver to obtain bit and Symbol
lock.
Components may have device-specific ways to configure N_FTS values
to advertise during Link training. Define an n_fts array with an
entry for each supported data rate.
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@xxxxxxxxxxxxxxxx>
> ---
> - This change was suggested in this patch: https://lore.kernel.org/all/20241211060000.3vn3iumouggjcbva@thinkpad/
> ---
> dtschema/schemas/pci/pci-bus-common.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/dtschema/schemas/pci/pci-bus-common.yaml b/dtschema/schemas/pci/pci-bus-common.yaml
> index 94b648f..f0655ba 100644
> --- a/dtschema/schemas/pci/pci-bus-common.yaml
> +++ b/dtschema/schemas/pci/pci-bus-common.yaml
> @@ -128,6 +128,16 @@ properties:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [ 1, 2, 4, 8, 16, 32 ]
>
> + nfts:
> + description:
> + Number of Fast Training Sequence (FTS) used during L0s to L0 exit for bit
> + and Symbol lock.
I think it's worth using the "number of Fast Training Sequences
required by the Receiver" language from the spec to hint that these
values will be used to program a component with the number of FTSs
that it requires as a Receiver, and the component will advertise this
number as N_FTS during Link training.
n_fts:
description:
The number of Fast Training Sequences (N_FTS) required by the
Receiver (this component) when transitioning the Link from L0s
to L0; advertised during initial Link training
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 5
> + items:
> + maximum: 255
> +
> reset-gpios:
> description: GPIO controlled connection to PERST# signal
> maxItems: 1
> @@ -150,6 +160,12 @@ properties:
> description: Disables ASPM L0s capability
> type: boolean
>
> + aspm-l0s-entry-delay-ns:
> + description: Aspm l0s entry delay.
> +
> + aspm-l1-entry-delay-ns:
> + description: Aspm l1 entry delay.
s/Aspm/ASPM/
s/l0s/L0s/
s/l1/L1/
(I mentioned these earlier in the conversation you pointed to above,
but they got missed)
Also, to match surrounding items:
s/\.$//
> vpcie12v-supply:
> description: 12v regulator phandle for the slot
>
> --
> 2.34.1
>
