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

[Vladimir Oltean]

On Mon, Jun 12, 2023 at 04:46:16PM -0400, Sean Anderson wrote:
> On 6/12/23 12:33, Vladimir Oltean wrote:
> > On Mon, Jun 12, 2023 at 10:35:21AM -0400, Sean Anderson wrote:
> >> > And if SERDES protocol switching was not physically possible, would this
> >> > patch set still have value?
> 
> More to the point, did you make any progress in this area?

Aha. It is two email exchanges later that you've thought of asking that.

No, I haven't made progress. Though I managed to get some extra pointers
and things to try out, and at this stage I am the limiting factor. I will
let you know once the investigation has reached a conclusion.

So many things depend on whether major SERDES protocol reconfiguration
is possible, that if I were you, my question would be just that, instead
of the equivalent of "Vladimir, when can my driver be merged ???".
I understand how incredibly frustrating it is that the responses are
coming in so slowly, and this is the reason why I am responding at all
to your pings even if I have essentially nothing new to say.

And it's not that you don't care whether protocol reconfiguration is
possible or not - you do, but at the same time you're overcome with this
strong attachment to your solution just because it is yours, that I
don't know how to deal with.

> 2222 also does not work, as outlined above.
> 
> The clocking is incompatible, and must be fixed by software.
> 
> The only thing self-inflicted is NXP's conflicting design.

The way things are supposed to work (*if* this works at all) is that the
reset state machine starts with a supported PLL / refclk configuration
that permits a certain subset of protocols, and the SERDES protocols can
be changed from the reset state, as desired, for the individual lanes.

What is self-inflicted is that the refclks on your board design are not
supportable by any reset state machine configuration, and wiring them
that way was a conscious decision. Did your company's board designers
receive the recommendation to disconnect RESET_REQ from NXP, and has NXP
said that the end result will be something that continues to be supportable?
I've searched the customer support database and the answer seems to be no.
In any case, if you have to disconnect RESET_REQ from the SoC to make
the driver in this form useful, then... yeah, no. You're obviously free
to do whatever you want with your products, but that's not how mainline
Linux works, it needs to be useful beyond you.

If protocol switching works, I will maintain that your board should have
wired the refclks to PLLs the other way around (which is supported by
the RCW), and then proceed to do protocol switching to reach the desired
configuration.

So you can see that many things change based on whether protocol reconfig
is possible or not. The patch set presented here looks exactly like the
product of someone infatuated with form over substance, and who misses
the overall picture. My belief is that if you shift your attitude from
"is the work done?" to "is the work generally useful?", the interactions
will improve by a lot.

> > Have you actually tested changing individual lanes from SGMII to SGMII 2.5?
> > I know it works on LS1028A, but I don't know if that's also true on LS1046A.
> > Your comments do say "LYNX_PROTO_SGMII25, /* Not tested */".
> 
> Not yet. 

Aha. So concretely, what makes you so confident with moving this forward?
You like the code to just be there, no?

It helps your board, I understand. But not everything has to stay in
mainline if it's not useful for others, and I've proposed an alternative
solution which I'm not sure how seriously you took.

> This driver would also be a good place to add the KR link training with
> NXP tried to upstream a few years ago.

Well, speaking as someone who is now also tasked with the copper backplane
support, believe me that I know that, and this is why I'm so desperate
with the logic you're trying to push forward. It's clear that we should
try to collaborate rather than try to push individualistic non-tested
non-solutions.

> > Assuming a start from SERDES protocol 3333 with PLL mapping 2222,
> > this protocol change implies powering on PLL 1 (reset state machine
> > wants it to be disabled) and moving those lanes from PLL 2 to PLL 1.
> > 
> > At first sight you might appear to have a point related to the fact that
> > PLL register writes are necessary, and thus this whole shebang is necessary.
> > But this can all be done using PBI commands, with the added benefit that
> > U-Boot can also use those SERDES networking ports, and not just Linux.
> > You can use the RCW+PBL specific to your board to inform the SoC that
> > your platform's refclk 1 is 156 MHz (something which the reset state
> > machine seems unable to learn, with protocol 0x3333). You don't have to
> > put that in the device tree. You don't have to push code to any open
> > source project to expose your platform specific details. Then, just like
> > in the case of the Lynx 28G driver on LX2160, the SERDES driver could
> > just treat the PLL configuration as read-only, which would greatly
> > simplify things and eliminate the need for a clk driver.
> > 
> > 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?

> > In short, I believe the reasons you have cited do not justify the
> > complexity of the solution that you propose.
> 
> The work is done,

:)

> and it is certainly more flexible than what you propose. E.g. imagine
> a clock which needs to be configured before it has the correct
> frequency. Such a thing is difficult to do in a PBI solution, but is
> trivial in Linux.

So "a clock which needs to be configured" means a programmable clock
generator that provides the refclk to the PLL, correct?

With QorIQ/Layerscape SoCs, I imagine that case would typically be done
by a board CPLD during the boot sequence, because if the PLL refclks
don't have the right frequency, the main SoC doesn't start. You've hacked
the RESET_REQ signal so you don't have that problem. But surprise -
others haven't - so it's not exactly a relevant argument in favor.

It's clear that the hardware has limitations that have impact upon the
way in which both boards and software is designed. Because you don't
know whether protocol reconfig is possible, you don't know *if* it is
possible, *under what circumstances* it will be possible. What if XFI
only works with 156 MHz provided to PLL 2, and not to PLL 1? You're
trying to push a non-final solution as a final solution.

The programmable refclk generator that is reconfigured at runtime is
another can of worms, which I'm not sure can be feasibly implemented on
this hardware given the fact that multiple lanes share one PLL, and
there are many more lanes (4 or 8) than PLLs (2). Again, I need to see
some practical functionality that this patch set provides.

Do you _actually_ have a programmable clock generator that the CPLD
can't program, or is this a "what if" situation?

More to the point of the "flexibility" that you claim. You haven't
addressed my point of networking over the SERDES ports in U-Boot.
You don't need that - I'm clear with that, otherwise we'd be having this
conversation on the U-Boot mailing lists - but what if others, wanting
to follow your solution, would? Would you see that as an opportunity to
write even more code?