[PATCH v14 00/15] phy: Add support for Lynx 10G SerDes

[Vladimir Oltean]

On Fri, Aug 11, 2023 at 11:43:01AM -0400, Sean Anderson wrote:
> >> > > Here is an illustrative example (sorry, I don't have a board with the
> >> > > right refclk on that PLL, to verify all the way):
> >> > > 
> >> > > ... snip ...
> >> > 
> >> > (which of course complicates the process of building the PBIs...)
> >> 
> >> Maybe this is the language barrier, but what are you trying to say here?
> > 
> > I said that I don't understand. Can you please clarify what you were
> > trying to transmit with this comment?
> 
> Well, right now I produce my RCWs by generating a second RCW with e.g.
> 1133 replaced by 3333. But doing this is a more involved change. Just a
> minor issue, really.

Ok, so a comment related to your private build environment, and not a
counter-argument to the solution. It wasn't clear.

> That said, I don't think this is the best approach moving forward.
> Much like many other platforms, users should be able to plug in an SFP
> module and Linux should configure things appropriately. An RCW
> approach requires some kind of configuration tool to swap out the
> bootloaders, which isn't as good of a user experience.

I am quite familiar with the SFP use case you are talking about. SolidRun
requested that on LX2160 with the Lynx 28G driver, and that works fine
there. What I am proposing is for the exact same approach to be used
with Lynx 10G as well.

Let me explain that approach, because your mention of "swapping out the
bootloaders" makes it appear as if you are not visualising what I am
proposing.

The Lynx SerDes family has 2 PLLs, and more lanes (4 or 8). Each lane
uses one PLL or the other, to derive its protocol frequency. Through the
RCW, you provision the 2 PLL frequencies that may be used by the lanes
at runtime.

The Lynx 28G SerDes driver reads the PLL frequencies in
lynx_28g_pll_read_configuration(), and determines the interface modes
supportable by each PLL (this is used by phylink). But it never changes
those PLL frequencies, since that operation is practically impossible in
the general sense (PLLs are shared by multiple lanes, so changing a PLL
frequency disrupts all lanes that use it).

So, you see, the RCW approach that I am proposing is not the RCW
approach that you are thinking about. I was never suggesting to swap the
bootloader when the user plugs in a different SFP. I am just suggesting
that the RCW is provisioned for 2 different PLL frequencies, and those PLL
frequencies give you 2 networking protocol speed options. Depending on
what each lane needs (the information comes from phylink), you can move
each lane to one PLL or the other, at runtime, in the Linux SerDes driver,
to support the speeds of 1G and 10G, or 10G and 25G. You can't get more
than 2 speeds at the same time with just 2 PLLs, and this is an
intrinsic limitation of the fact that there are just 2 PLLs.

If the RCW and board do not provision the PLL frequencies for more
than 1 lane speed, then no dynamic protocol switching is possible, and
the supported_interfaces of each lane contains a single bit: the
reset-time protocol.