On Tue, Sep 29, 2026 at 07:59:40PM +0200, Vincent Jardin wrote: > +/* > + * 2x40GE (XLAUI-4), dpmac.2 on LNA-LND and dpmac.1 on LNE-LNH, > + * protocol 20 builds the same. > + * > + * 40GE lanes run at 10.3125 Gbaud. LNmTGCR0/LNmRGCR0[BY_N_RATE_SEL] is > + * the lane rate as a fraction of the PLL clock: 011b (double) for 25G > + * and 100GE, 000b (full) for 40GE, so the lanes cannot stay on PLLF (fast) > + * and move to PLLS (slow).
I feel there's a bit of a misunderstanding here. The conclusion is correct (that 10G/40G lanes can't share the same PLL as 25G/100G lanes) but the justification is wrong, or at least very twisted. There is *no problem* with the cited reason that the different BY_N_RATE_SEL settings are why 10GbE/40GbE and 25GbE/100GbE protocols cannot coexist on a PLL. Simplified, a SerDes PLL has an input frequency (called refclk; REFCLK_SEL) and an output frequency (called clock net; FRATE_SEL). More importantly, in some cases: - it can produce its output frequency from two different input values (see Table 295. Valid SerDes RCW Encodings and Reference Clocks). Example: 10.3125 GHz clock net can be produced from 156.25 MHz, or from 161.1328125 MHz refclk - the same input frequency can be used to produce two different output values. Example: 161.1328125 MHz refclk can be used to produce 10.3125 GHz clock net, or 12.890625 GHz clock net. Each lane derives its frequency from one PLL's clock net or the other, and has its own independent BY_N_RATE_SEL divider/multiplier. The problem is exactly the second bullet: the 10GbE and 40GbE protocols require 10.3125 GBaud per lane (this is simple math - 10G at 64b/66b coding = 10G * 66/64). They can obtain this baud rate from the 10.3125 clock net with no divider or multiplier. Whereas the 25GbE and 100GbE protocols require 25.78125 GBaud (25G * 66/64), which they obtain from a clock net of 12.890625G GHz and multiplying by 2. So it's *not* that for 25G you need to multiply by 2 and for 10G you don't. It's the fact that a single PLL can produce a single clock net frequency, and no clock net frequency can satisfy both 10G and 25G. > + * > + * Protocol 13 powers PLLS down only through PLLnRSTCTL[DIS], which > + * software can clear. Technically "does not power PLLS up" rather than "powers it down". > PLLS then gets the values a board booted with > + * protocol 20 reads back. This sentence doesn't make too much grammatical sense; I don't understand what you mean by it. > They are for a 161.1328125 MHz reference clock: So SRDS_PRTCL_S1 does not influence the refclk that the PLL expects, instead SRDS_PLL_REF_CLK_SEL_S1 does. How this works is: whenever SRDS_PRTCL_S1 requests a protocol whose clock net can be derived from 2 different refclk frequencies, SRDS_PLL_REF_CLK_SEL_S1 decides whether the clock net will be derived from the lower refclk frequency (if 0) or the higher frequency (if 1). In the case of 40GbE (the protocol selected by SRDS_PRTCL_S1=20): - if SRDS_PLL_REF_CLK_SEL_S1=0, PLLS will be expected to have refclk 156.25 MHz - if SRDS_PLL_REF_CLK_SEL_S1=1, PLLS will be expected to have refclk 161.1328125 MHz So if I understood correctly what you meant to say, it is not quite correct, because protocol 20 does not exclusively dictate PLLS's expected refclk. > the board has to feed PLLS that, which the RCW does not > + * describe for protocol 13 and which cannot be checked from here. > + */ Technically, the board does not *have* to feed PLLS a refclk frequency. We have the SRDS_INTRA_REF_CLK_S1 option, through which PLLS can be told to internally use PLLF's input frequency. Due to your use of 25GbE/100GbE on that other PLL, I deduce PLLF is also provisioned for 161 MHz refclk, thus SRDS_INTRA_REF_CLK_S1 is a viable alternative for this only configuration that you support. I'm saying this because your patch is presenting "2x40g" as a single configuration, when in reality PLLS can also have a 156.25 MHz refclk and a 10.3125 FRATE_SEL, but (perhaps confusingly to some, who will try to reuse your work), this configuration will not be supported. Is this what you intend? It doesn't necessarily read as a conscious decision.
