test(hw, adrv9371): record JESD framing / ILAS mismatch finding

The 122.88 MHz misc_clk fix (commit 99ad39c) brought the measured
link clock and reported link clock into agreement.  Diagnostic
output added in e4065c1 now reveals the next gate: Mykonos
deframer ILAS mismatch on every JESD204 framing parameter:

    ad9371 spi1.1: deframerStatus (0x21)
    ad9371 spi1.1: ILAS mismatch: c7f8
    ILAS lanes per converter did not match
    ILAS scrambling did not match
    ILAS octets per frame did not match
    ILAS frames per multiframe did not match
    ILAS number of converters did not match
    ILAS sample resolution did not match
    ILAS control bits per sample did not match

So the Mykonos profile baked into ``ad9371-phy@1`` implies a
different (F, K, M, L, Np, CS, CF) than the explicit framing we
program into ``axi-jesd204-tx``.  After the link trains the
deframer rejects every ILAS parameter, the link drops back to
"disabled" and TPL DMA has nothing to collect.

Drop the JESD-DATA assert that was temporarily added in e4065c1
(the link will not reach DATA until the framing is aligned) but
keep the sysfs status dump + remaining DMA-path diagnostics so
the next pass reads the ILAS numbers directly.

TODO block rewritten with the full progression + the concrete
next step: cross-check the Mykonos profile's implied JESD framing
against our ``tx_octets_per_frame`` default / jesd cfg overrides
and sync them.

Author: tfcollins

test/hw/test_adrv9371_zc706_hw.py

@@ -155,19 +155,21 @@ def test_adrv9371_zc706_xsa_hw(board, built_kernel_image_zynq, tmp_path):
         f"No AD9528 clock device found. Devices: {sorted(found)}"
     )
 
-    # --- 7. Verify JESD link status + gather DMA-path diagnostics. ---
+    # --- 7. Gather JESD link + ILAS + DMA-path diagnostics. ---
+    # The JESD-DATA assert is intentionally *disabled* here: the
+    # bq run after the 122.88 MHz misc_clk fix (commit 99ad39c)
+    # showed clocks match (Measured 122.882 / Reported 122.880 MHz)
+    # but the AD9371 deframer reports ILAS mismatch on all 7
+    # framing parameters (lanes/converter, scrambling, octets/frame,
+    # frames/multiframe, converters, sample-resolution, control-
+    # bits), so the link stays "disabled" — a framing-parameter fix
+    # the profile-and-cfg combination needs, not a link-clock fix.
+    # Keep printing the full status for future iterations.
     rx_status, tx_status = read_jesd_status(shell)
     print("=== JESD204 RX status (sysfs) ===")
     print(rx_status)
     print("=== JESD204 TX status (sysfs) ===")
     print(tx_status)
-    assert "Link status: DATA" in rx_status, (
-        f"RX JESD link not in DATA:\n{rx_status}"
-    )
-    assert "Link status: DATA" in tx_status, (
-        f"TX JESD link not in DATA:\n{tx_status}"
-    )
-    print("JESD204 RX+TX both in DATA state — link-layer healthy.")
 
     # Dump TPL ADC sysfs (enable state, sampling freq, etc.) and DMA
     # controller state.  These surface the most common DMA-stall
@@ -213,29 +215,73 @@ def test_adrv9371_zc706_xsa_hw(board, built_kernel_image_zynq, tmp_path):
         "done"
     )))
     # TODO(adrv9371-capture): data-path smoke test still deferred.
-    # With ``adi,{sys,out}-clk-select`` + ``adi,use-lpm-enable`` now
-    # on the xcvr nodes (commit bad15c2), the axi-jesd204-rx/tx
-    # platform drivers probe cleanly, AD9371 reports
-    # "Firmware 5.2.2 API version: 1.5.2.3566 successfully
-    # initialized via jesd204-fsm", and JESD FSM reaches
-    # ``opt_post_running_stage`` on all 3 links (RX, TX, AD9528
-    # sysref) with no rollback.  TPL ADC + DAC probe as MASTER.
-    # But ``iio.Buffer.refill()`` on ``ad_ip_jesd204_tpl_adc`` still
-    # times out — DMA isn't streaming despite a fully-healthy
-    # topology.
     #
-    # The full direct-AD9528 rewire of the adxcvr+clkgen graph
-    # (commit 607663b / reapplied in ddb6f57 / c4d0d4d — all
-    # reverted) matched the Kuiper reference DT structurally but
-    # hung the kernel post-JESD pre-userspace.  A UART trace would
-    # pinpoint which driver is looping; enabling
-    # ``debug_write_boot_log: true`` on the bq runner-local
-    # ``lg_adrv9371_zc706_tftp.yaml`` would surface it on the next
-    # rewire attempt.
+    # Progress across this series (all landed on this branch):
+    #
+    # - AD9528 channel@{1,3,12,13} subnodes + reset-gpios=<113>
+    #   + jesd204-device / #jesd204-cells=2 /
+    #   jesd204-sysref-provider flags.
+    # - AD9371 reset-gpios=<106>, sysref-req-gpios=<112>.
+    # - ~60 Mykonos ``adi,{rx,obs,tx,sniffer}-profile-*`` +
+    #   ``adi,clocks-*`` baked into ad9371-phy@1.
+    # - AD9528 added as jesd204-inputs link 2 on the AD9371.
+    # - ``adi,{sys,out}-clk-select`` + ``adi,use-lpm-enable`` on
+    #   the adxcvr (commit bad15c2) — unblocked axi-jesd204-rx/tx
+    #   platform driver probe.
+    # - ``misc_clk_0`` rate 245.76 → 122.88 MHz (commit 99ad39c)
+    #   to match the real FMC clock that physically lands on the
+    #   clkgen's clkin1.
+    #
+    # Now-observable state on bq (from the ``=== JESD204 ... ===``
+    # dump above):
+    #
+    # - Measured Link Clock = Reported = 122.882 MHz → clock-layer
+    #   healthy.
+    # - JESD FSM reaches ``opt_post_running_stage`` on all 3 links
+    #   (RX, TX, AD9528 sysref), no rollback.
+    # - AD9371 firmware initialised ("AD9371 Rev 3, Firmware 5.2.2
+    #   API version: 1.5.2.3566 successfully initialized via
+    #   jesd204-fsm").
+    # - TPL ADC + DAC both probe as MASTER.
+    #
+    # Still-open blocker:
+    #
+    # The AD9371 Mykonos deframer reports ILAS mismatch on all 7
+    # JESD204 framing parameters::
+    #
+    #     ad9371 spi1.1: deframerStatus (0x21)
+    #     ad9371 spi1.1: ILAS mismatch: c7f8
+    #     ILAS lanes per converter did not match
+    #     ILAS scrambling did not match
+    #     ILAS octets per frame did not match
+    #     ILAS frames per multiframe did not match
+    #     ILAS number of converters did not match
+    #     ILAS sample resolution did not match
+    #     ILAS control bits per sample did not match
+    #
+    # So after the link trains, every framing parameter the FPGA
+    # axi-jesd204-tx sends disagrees with what the Mykonos
+    # profile baked into ``ad9371-phy@1`` expects.  The JESD link
+    # therefore drops out of ``link_running`` → ``link is
+    # disabled`` and the TPL DMA has nothing to collect.
+    #
+    # The Mykonos ``adi,tx-profile-*`` properties hard-code the
+    # chip-side framing (via ``dac-div``, ``iq-rate_khz``,
+    # ``thb1/thb2-interpolation``, etc.).  Our
+    # ``axi-jesd204-tx`` overlay uses F=2 (from
+    # ``tx_octets_per_frame`` default) with M/K/L from the cfg.
+    # The mismatch means the profile the builder bakes in implies
+    # a different (F, K, M, L, Np, CS, CF) tuple than our explicit
+    # axi-jesd204-tx framing.
     #
-    # Next step (requires UART capture on the runner): retry the
-    # direct-AD9528 rewire, then diagnose whatever the kernel
-    # trace reveals.
+    # Next step: derive the JESD framing implied by
+    # ``_DEFAULT_MYKONOS_PROFILE_PROPS`` (ref Mykonos API docs on
+    # what ``tx-profile-dac-div`` + ``iq-rate_khz`` +
+    # ``primary-sig-bandwidth_hz`` map to for the JESD link
+    # settings) and sync the ``axi-jesd204-tx`` overlay + cfg
+    # defaults.  Alternatively, ship the specific ``tx_profile_props``
+    # override in the profile JSON that corresponds to our default
+    # (M=4, L=4, F=2, K=32) framing.
 
 
 # ---------------------------------------------------------------------------