On 4/29/23 13:24, Vladimir Oltean wrote:

On Wed, Apr 26, 2023 at 10:50:17AM -0400, Sean Anderson wrote:

quoted

quoted

I need to catch up with 14 rounds of patches from you and with the
discussions that took place on each version, and understand how you
responded to feedback like "don't remove PHY interrupts without finding
out why they don't work"

All I can say is that

- It doesn't work on my board
- The traces are on the bottom of the PCB
- The signal goes through an FPGA which (unlike the LS1046ARDB) is closed-source

I don't understand the distinction you are making here. Are the sources
for QIXIS bit streams public for any Layerscape board?

Correct. The sources for the LS1046ARDB QIXIS are available for download.

quoted

- The alternative is polling once a second (not terribly intensive)

It makes a difference to performance (forwarded packets per second), believe it or not.

I don't. Please elaborate how link status latency from the phy affects performance.

quoted

I think it's very reasonable to make this change. Anyway, it's in a separate
patch so that it can be applied independently.

Perhaps better phrased: "discussed separately"...

quoted

quoted

Even if the SERDES and PLL drivers "work for you" in the current form,
I doubt the usefulness of a PLL driver if you have to disconnect the
SoC's reset request signal on the board to not be stuck in a reboot loop.

I would like to emphasize that this has *nothing to do with this driver*.
This behavior is part of the boot ROM (or something like it) and occurs before
any user code has ever executed. The problem of course is that certain RCWs
expect the reference clocks to be in certain (incompatible) configurations,
and will fail the boot without a lock. I think this is rather silly (since
you only need PLL lock when you actually want to use the serdes), but that's
how it is. And of course, this is only necessary because I was unable to get
major reconfiguration to work. In an ideal world, you could always boot with
the same RCW (with PLL config matching the board) and choose the major protocol
at runtime.

Could you please tell me what are the reference clock frequencies that
your board provides at boot time to the 2 PLLs, and which SERDES
protocol out of those 2 (1133 and 3333) boots correctly (no RESET_REQ
hacks necessary) with those refclks? I will try to get a LS1046A-QDS
where I boot from the same refclk + SERDES protocol configuration as
you, and use PBI commands in the RCW to reconfigure the lanes (PLL
selection and protocol registers) for the other mode, while keeping the
FRATE_SEL of the PLLs unmodified.

 From table 31-1 in the RM, the PLL mapping for 1133 is 2211, and the
 PLL mapping for 3333 is 2222. As a consequence, for 1133, PLL 2 must be
 156.25 MHz and PLL 1 must be either 100 or 125 MHz. And for 3333, PLL 2
 must be either 100 or 125 MHz, and PLL 1 should be shut down (as it is
 unused). This conflict for PLL 2 means that the same reference clock
 configuration cannot work for both 1133 and 3333. In one of the
 configurations, SRDS_RST_RR will be set in RSTRQSR1. On our board,
 reference clock 1 is 156.25 MHz, and reference clock 2 is 125 MHz.
 Therefore, 3333 will fail to boot. Unfortunately, this reset request
 occurs before any user-configurable code has run (except the RCW), so
 it is not possible to fix this issue with e.g. PBI.

 --Sean
 not