Re: [PATCH V1] schemas: pci: bridge: Document PCI L0s & L1 entry delay and nfts

On Mon, Jan 6, 2025 at 5:32 PM Bjorn Helgaas <[email protected]> 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 <[email protected]>
> > ---
> > - 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.