There appears to be a day one bug in the ad9144.c Linux and No-OS driver in the JESD link setup. For the Linux ad9144.c driver at line 147, third write in transport setup, to 0x300 it is incorrectly writing a 0x01 at this point enabling the link 0 before it has been setup correctly.
At this point in the transport setup the write to 0x300 for single link should be 0x00. Only if setup in dual link mode should the upper bit 3 and 2 be set for 0x300 at this point to enable which link 0 or link 1 registers are being set; per example step 3 in data sheet at page 84. See also data sheet page 26 Table 19 Transport Layer Settings.
The 0x300 write to enable link 0, 0x01, does occur properly at line 211 of the ad9144.c driver after the data link layer sync setup is done.
Note, that the current default 0x00 LMFC delay, 0x304 and 0x305 settings, do seem to place the LMFC count in the correct range for
gaining deterministic latency on a AD9144 FMC and ZC706 based design along with the following devicetree changes.
Also, can one please make sure and update the wiki Linux support driver site for jesd204B and jesd204B_gt such as they better reflect the current Linux devicetree settings with the new TX - RX link setting method.
For jesd204b_gt.c the devicetree entry adi-sysref-external-enable must used for the inbound sysref clock from clock chip to FPGA to be enabled.
For jesd204b_v51.c it appears that the devicetree entry xlnx,sysref-always-enabled should be set if a periodic external sysref clock is used.
It would be good if these devicetree settings needed to get deterministic latency in the transmit JESD interface with ad9144,ad9152 DAC's are documented with comments, add them to the DAQ2 FMC devicetree settings too.
All runs now and my digital markers are syncing up in time well with pulse waveform out of ad9144 in custom design over power cycles, It seems to always power up also.