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

[Bjorn Helgaas <helgaas@kernel.org>]

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@oss.qualcomm.com>
> ---
> - 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
>