Skip to content

ADF41513/0 and ADRF5702/3 support - #764

Open
rodrigo455 wants to merge 5 commits into
mainfrom
dev/adf41513
Open

ADF41513/0 and ADRF5702/3 support#764
rodrigo455 wants to merge 5 commits into
mainfrom
dev/adf41513

Conversation

@rodrigo455

@rodrigo455 rodrigo455 commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

ADF41513/0 and ADRF5702/3 support

Adds driver support for the ADF41513/0 PLL frequency synthesizers and extends the
ADRF5720 digital attenuator to cover the ADRF5702 and ADRF5703. Both additions
are built on a new features of the device_base class, which allows for multi-part compatible
device handling.

adi.adf4151x — driver for the ADF41513/0 26.5 GHz Integer-N/Fractional-N PLL,
exposing output frequency, frequency resolution, powerdown.

adi.adrf5720 — compatible_parts now includes adrf5702 and adrf5703 alongside the
existing adrf5720, adrf5730, and adrf5731.

References:

Type of change

  • Bug fix
  • New device class interface
  • New feature on an existing class
  • Breaking change
  • Documentation only
  • Test or CI only

How has this been tested?

State explicitly whether this was tested against real hardware, an emulated context (iio-emu), or not run. Name the part(s) and the context URI or board used.

  • Hardware / emulation:
  • Commands run (e.g. python3 -m pytest -k ad4080 --adi-hw-map):
    • python -m pytest test/test_adf41513.py --uri ip:10.32.22.147 --skip-scan
    • pytest --emu --skip-scan test/test_adf41513.py
  • Result:

Test configuration

  • Kernel / libiio version: v0.26
  • OS: Linux 6.12
  • FPGA carrier (if applicable): ADMFM8000

Documentation

  • No documentation change needed
  • Updated existing docs under doc/source/
  • Added a new device page and linked it from the relevant toctree

New device class interfaces

Skip this section if the PR does not add a new device class.

  • Class extends one of the common base classes in adi.device_base (rx_chan_comp, tx_chan_comp, or a _no_buff variant). If not, explain why in the description. See the Device Base Classes developer doc page.
  • compatible_parts lists every part number this class supports
  • Part numbers added to supported_parts.md (verify with invoke checkparts)
  • Emulation context (xml_gen, not iio_genxml) added under test/emu/ and referenced from a test
  • Tests added that run against the emulation context in CI

Checklist

  • invoke precommit passes locally
  • All commits are signed off (Signed-off-by: Name <email>)
  • No new warnings from the build or doc generation
  • Dependent changes in libiio, kernel, or HDL are merged and referenced

Recommend the usage of a virtual environment instead of:
'sudo pip install'

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
@github-actions

Copy link
Copy Markdown

Generated documentation for this PR is available at Link

@github-actions

github-actions Bot commented Jun 11, 2026

Copy link
Copy Markdown

Test Results

2 059 tests  +13     767 ✅ +13   3m 50s ⏱️ -33s
    1 suites ± 0   1 292 💤 ± 0 
    1 files   ± 0       0 ❌ ± 0 

Results for commit 32b4fc7. ± Comparison against base commit 8c68b72.

♻️ This comment has been updated with latest results.

@github-actions

github-actions Bot commented Jun 11, 2026

Copy link
Copy Markdown

IIO Context Coverage Report

New device classes in this PR: adf41510, adf41513, adf4151x

Minimum required total coverage: 75.0%

Summary

Hardware Device Attr Coverage Channel Attr Coverage Total Coverage Status
adf41513 0/1 (0.0%) 4/4 (100.0%) 4/5 (80.0%)
Untested attributes (click to expand)

adf41513

  • adf41513 device attrs untested: waiting_for_supplier

Coverage check passed. All new parts meet the 75.0% minimum total coverage.


Generated by IIO Context Coverage workflow

@rodrigo455
rodrigo455 requested a review from tfcollins June 22, 2026 13:49

@tfcollins tfcollins left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your compatible.py functionality already exists here https://github.com/analogdevicesinc/pyadi-iio/blob/main/adi/device_base.py

Your class should also not have so many register based operations. These should be debug attributes in the driver.

@rodrigo455

Copy link
Copy Markdown
Collaborator Author

Your compatible.py functionality already exists here https://github.com/analogdevicesinc/pyadi-iio/blob/main/adi/device_base.py

The devices covered here are not tx/rx devices. Also, device_base does not initializes shared_def.
Differences with device_base are explained in the PR description.

Will see if I can integrate compatible features into device_base.

Your class should also not have so many register based operations. These should be debug attributes in the driver.

will drop the register based properties for now.

Add features to device_base, so that it covers both wrapper-mode
(rx_chan_comp / tx_chan_comp) and standalone-mode (attribute-only
control devices) use.

- Add device_base.variant() staticmethod. Creates a derived class
pinned to a specific compatible part and appends the part to
compatible_parts. Supports per-part chip_info via **kwargs stored
in the new _device_info class dict.
- Extend __init__ to accept an optional uri argument. When provided,
device_base drives shared_def.__init__ itself and resolves _ctrl.
When omitted (wrapper mixin path), _control_device_name is set for
the wrapper's rx_def/tx_def to consume as before.
- In URI mode, device_name may be a driver name, a device label, or
an IIO device id. libiio's find_device handles all three. If it
can't resolve (or _control_device_name is left empty to signal
"match any compatible"), fall back to scanning ctx.devices against
compatible_parts.
- Normalize device_name to the resolved _ctrl.name after discovery
so per-part _device_info lookup and _rx/tx_data_device_name
assignments use the actual driver name.
- Validate the resolved _ctrl.name against compatible_parts (or the
variant-pinned _device_name subset) before applying chip_info.
- device_index is honored only in the wrapper path (via shared_def);
on the URI path, disambiguate multiple devices using a label or id
instead.

Wrapper classes (tx_chan_comp, rx_chan_comp, tx_chan_comp_no_buff,
rx_chan_comp_no_buff) are unchanged; they continue to call
device_base.__init__ without a uri and let rx_def / tx_def perform
the shared_def initialization.
- Leveraging device_base class for multi-device support;
- register and muxout definitions for debug;

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Leverage the device_base class and add adrf5702 and adrf5703 to compatible
parts list.

Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants