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

On 1/8/2025 2:12 AM, Bjorn Helgaas wrote:
> On Tue, Jan 07, 2025 at 07:49:00PM +0530, Krishna Chaitanya Chundru wrote:
>> On 1/6/2025 8:37 PM, Rob Herring wrote:
>>> On Mon, Jan 6, 2025 at 3:33 AM Krishna Chaitanya Chundru
>>> <[email protected]> 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.
>>>>
>>>> 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.
> 
>>> Do these properties apply to any link like downstream ports on a
>>> PCIe switch?
>>>
>> These applies to downstream ports also on a switch.
> 
> IIUC every PCIe component with a Link, i.e., Upstream Ports (on a
> Switch or Endpoint) and Downstream Ports (a Root Port or Switch), has
> an N_FTS value that it advertises during Link training.
> 
> I suppose N_FTS depends on the component electrical design and maybe
> the Link, and it only makes sense to have this n-fts property for
> specific devices that support this kind of configuration, right?  I
> don't think we would know what to do with n-fts for random plug-in
> Switches or Endpoints because there's no generic way to configure
> N_FTS, and we *couldn't* do it before the Link is trained anyway
> unless there's some sideband mechanism.
yes I agree with it, we have one such type of PCIe switch which has i2c
sideband mechanism = to program it before enabling link training. This
properties can be used for the switches which has side band mechanism.
> 
>>>> +    description:
>>>> +      Number of Fast Training Sequence (FTS) used during L0s to L0 exit for bit
>>>> +      and Symbol lock.
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    minItems: 1
>>>> +    maxItems: 5
>>>
>>> Need to define what is each entry? Gen 1 to 5?
>>>
>> yes there are from Gen1 to Gen 5, I will update this in next patch these
>> details.
> 
> Components are permitted to advertise different N_FTS values at
> different *speeds*, not "GenX" (PCIe r6.0, sec 4.2.5.6)
> 
> The spec discourages use of Gen1, etc because they are ambiguous (sec
> 1.2):
> 
>    Terms like "PCIe Gen3" are ambiguous and should be avoided. For
>    example, "gen3" could mean (1) compliant with Base 3.0, (2)
>    compliant with Base 3.1 (last revision of 3.x), (3) compliant with
>    Base 3.0 and supporting 8.0 GT/s, (4) compliant with Base 3.0 or
>    later and supporting 8.0 GT/s, ....
> 
> We're stuck with the use of genX for max-link-speed, but we should use
> speeds when we can for clarity, e.g., in the description here.
Ack, that's why I tried to mention data rates instead of gen in the
commit text.

- Krishna Chaitanya.