On Mon, Jan 6, 2025 at 5:32 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
>
> 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:
n-fts
Underscores are discouraged.
