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?
