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
<krishna.chundru@xxxxxxxxxxxxxxxx> 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.
