AD9088 API v2.0.0 Update & Related Changes#3179
Conversation
c587bdb to
061ae81
Compare
310f0c8 to
cd11d9d
Compare
…0.1.3 Added: - API - Added support for AD9088 - API - Support for a new Profile format that consolidates and improves the data structures used by the part - this is a breaking change for Profile versions prior to V10. See Components Section below for Profile version - API - Integrated support for external trigger-based frequency hopping - API - New function to read part number with X-grade or B-grade and SW trim information (SW Trim 1/3/5) - FW - Allow ADC/DAC PN signal inversion based on user Profile settings Changed: - API - Some code cleanup and optimization by deleting unused code - API - Converted frequency representations from Hz to uHz (microhertz) throughout the ADF4030 driver and example code - this is a breaking change - FW - Upgrade device Profile. See Components Section below for Profile version - FW - For SerDes Rx, a number of bridging cal settings come from device Profile - FW - Device clock frequency variable changed from kHz to Hz - FW - Define the P-N inversion of the differential ADC/DAC RFIO in the device Profile - FW - 4D slice mode switching optimization - FW - Optimized receiver handling of overrange signal conditions Deprecated: - API - adi_apollo_clk_mcs_internal_sysref_per_set(), sync_logic_reset(), adi_apollo_jrx_subclass_set(), adi_apollo_clk_mcs_trig_reset_serdes_enable(), adi_apollo_adc_tlines_offset_set(), hsci_regio_rmw_write32() Fixed: - API - Bug fixed in adi_apollo_tmode_config_set(). Previously, the function ignored the resolution parameter and always set 16-bit resolution - API - Bug fixed in adi_apollo_cnco_profile_load() whereby an incorrect value could be written to the Profile when less than a full Profile array was being loaded - API - Bug fixed in tx_txpath_misc_configure() whereby register values were not updated - API - Increased delay after freezing of ADC background calibration before executing ADC slice mode switch within the slice mode switch prepare API function - FW - Bug fixed whereby MCS side-B was not being updated correctly during tracking calibration with dual clocking Errata: - API - ADF4030-FPGA Time-of-Flight measurement may time out when operating at low BSYNC frequencies - API - AD9084-SE ADC performance has not been fully optimized Supported: - AD9088 - AD9084 Components: - Device Driver API 2.0.10 - Firmware 2.0.6 - Device Profile 10.1.28 Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
…SREF divider Add adi,subclass = <1> to all four TRX nodes and compute LTC6953_AION_BSYNC_6_DIVIDER dynamically from FREQ_J1_MHz / SYSREF_CLK_MHz. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
ad9088_gpio_setup() returned -EINVAL when the adi,gpio-exports property was not present in the device tree, preventing probe on boards that don't need GPIO exports. Return 0 instead since the property is optional. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
…amping Update ADF4382_PHASE_BLEED_CNST_DIV from 285 to 250 and replace the simple 8-bit mask with proper bounds checking and clamping for the phase adjust register value. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
… to u32 Add debugfs read/write support for mcs_track_decimation allowing runtime adjustment of the MCS tracking calibration TDC decimation rate. Change mcs_track_decimation from u16 to u32 to match the API. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
a94bd28 to
4c28bfe
Compare
nunojsa
left a comment
There was a problem hiding this comment.
Looks good. Just some minor comments from my side
arch/arm64/boot/dts/xilinx/versal-vck190-reva-ad9088-204C-M8-L2-NP16-8p0-8x4.dts
Outdated
Show resolved
Hide resolved
arch/microblaze/boot/dts/vcu118_quad_ad9084_revB_ext_second.dts
Outdated
Show resolved
Hide resolved
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Align the debugfs MCS tracking calibration path with the JESD204 FSM implementation: - Move ADF4382 auto-align enable and phase adjustment (125) into ad9088_mcs_tracking_cal_setup() so both FSM and debugfs paths configure the ADF4382 before foreground tracking runs - Remove the now-duplicate ADF4382 setup from the JESD204 FSM post_setup_stage1 handler - Add adi_apollo_mcs_cal_tracking_enable(device, 0) to the debugfs bg_track_cal_run teardown path (write 0), matching the FSM teardown which calls both abort and tracking_enable(0) Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Remove the FIXME workaround that patched profiles with version patch < 3 by modifying reserved_cfg fields and forcing sysref_present. This is no longer needed now that all profiles have been updated to v10.1.3+. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
…ia DT When the device tree overrides the JESD subclass to a non-zero value (subclass 1), ensure that at least one SYSREF input is marked as present. If neither side A nor side B SYSREF is already configured in the profile, enable the center SYSREF so that deterministic latency synchronization can function correctly. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
ADC slice mode read/write and the adc_mode_switch_enable_set call during setup are not supported in 8T8R profiles. Guard these paths with is_8t8r checks to avoid errors on 8T8R configurations. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
…le array OOB
Fix several 8T8R channel mapping bugs in the IIO channel-to-hardware
block mapping function:
1. TX/RX FDUC/FDDC logical-to-physical conversion: The xbar encoding
interleaves bands per channel (TXn*4 + BAND*2 + Q), but the mux
hardware uses physical numbering where all BAND0 come first (0-3)
then BAND1 (4-7). Convert using lookup table {0,4,1,5,2,6,3,7}.
Without this, TX fine NCOs target wrong hardware blocks and RX
channels only see a subset of CDDCs/ADCs.
2. TX mux0_sel lookup: mux0_sel[] is indexed by DAC number with the
value selecting a mod-switch output, not indexed by CDUC. For 8T8R,
the modsw mapping swaps CDUCs 1/2. Search mux0_sel[] for the
matching modsw output to find the correct DAC.
3. RX mux0_out_adc_sel indexing: The array is indexed by CB_OUT number,
not CDDC number. Add cddc_to_cbout[] translation for 8T8R.
4. Profile array OOB: tx_cduc[]/rx_cddc[] have 2 entries per side but
8T8R hardware CDUC/CDDC numbers go 0-3. Similarly tx_fduc[]/rx_fddc[]
have 4 entries but physical numbers go 0-7. Add fddc_pi/cddc_pi
profile index fields to chan_map, computed once with modular indexing
(% CDUCS_PER_SIDE, % FDUCS_PER_SIDE). This fixes the "Invalid
adi_apollo_cduc_ratio_e enum" error on channels 2-3.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
The CFIR data path switch only handled FDDC masks for 4T4R (A0-A3, B0-B3). For 8T8R, FDDCs 4-7 share the same CFIR instances as 0-3 but use data paths DP_2 and DP_3 instead of DP_0/DP_1. Without this, probing an 8T8R profile logs "Unhandled FDDC number" errors for all upper-band FDDCs. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
In 8T8R mode, BMEM pairs share SRAM: A0/A2, A1/A3, B0/B2, B1/B3 all map to the same physical SRAM addresses. When both channels of a pair are captured, the hardware interleaves their data — even words belong to the primary channel, odd words to the secondary. Without this fix, both channels in a shared pair read identical raw data from the same SRAM address, producing duplicate waveforms. Fix by: 1. Doubling the SRAM capture range (end_addr) for 8T8R to account for the interleaving overhead — each channel only gets every other word. 2. After reading, deinterleave in-place: extract even words into the primary channel's buffer and odd words into the secondary's, then halve word_count for the demux loop. The in-place deinterleave is safe because the destination index is always less than the source index (dst[i] from src[2*i]). Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Setting spi_txen_en and spi_rxen_en to !!val caused the hardware to fall back to pin control mode when disabling (val=0), because spi_txen_en=0 means "use TxEN/RxEN pin" rather than "disable via SPI". This made disable operations unreliable, depending on the physical pin state. Fix by always setting spi_txen_en and spi_rxen_en to 1 to remain in SPI control mode, and use spi_txen/spi_rxen to control the actual enable state. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
…d DTS variants Add DTS files for VCU118 quad AD9084 RevB external primary and second board configurations, for both default and 26.4 GHz lane rate profiles. These override the adf4030 node and configure JESD204 FSM stop states. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
4c28bfe to
ea6cfa6
Compare
|
Force pushed again - all review comments are addressed |
|
Seems like there are still some CI errors on the API. To make it easier, you can run those builds locally with (example for zynqmp):
Just make sure you properly export ARCH and CROSS_COMPILE and it should worok |
Suppress frame-larger-than and enum-conversion for some files in the AD9088 API. Ideally we would fix the BU APIs and get those fixes "upstream". Signed-off-by: Jorge Marques <jorge.marques@analog.com>
|
Pushed the api suppression, just to note that the diff between gh and azure build.sh is that azure is doing, before compiling there are many suppressions everywhere that is concerning, even |
| ad9088_drv-y += public/src/adi_apollo_startup.o | ||
|
|
||
| # Ideally this hack would go away but we would need to make sure the fixes land into | ||
| # the BU APIs. |
There was a problem hiding this comment.
Yes, for navassa I made sure of that but ultimately I would argue that's the decision of whoever maintains the driver containing these APIs. I guess the below is the better we can do so that we can be a bit more strict in CI with the code we "own"
I think that for CI, kind of makes sense (and it is the default nowadays for upstream If I'm not mistaken). But as you said, we're doing some global suppressions also in azure. So, starting fresh in gh, we could maybe do it better
Indeed. Ideally we would do the suppression in the kernel at the driver level (instead of doing it globally as in azure). I mean, ideally we would fix the warning but it is what it is :). Also note, that some warnings might not be really not related to our code so it's a bit of a difficult thing to handle. |
PR Description
API & Firmware Update
Debugfs & DT
DTS
Other