ADRV9026/ADRV9029 Integrated Radio Frequency Transceiver Linux device driver [Analog Devices Wiki] (2024)

Table of Contents

• ADRV9026

• ADRV9029

Note that the baseline device, ADRV9025, is used within this Wiki with functions/properties that are common to both devices.

• EVAL-ADRV9026/ADRV9029

The ADRV9026 is a highly integrated, radio frequency (RF) agile transceiver offering four independently controlled transmitters, dedicated observation receiver inputs for monitoring each transmitter channel, four independently controlled receivers, integrated synthesizers, and digital signal processing functions providing a complete transceiver solution. The device provides the performance demanded by cellular infrastructure applications, such as small cell base station radios, macro 3G/4G/5G systems, and massive multiple in/multiple out (MIMO) base stations.

The ADRV9029 is a highly integrated, radio frequency (RF) agile transceiver offering four independently controlled transmitters, dedicated observation receiver inputs for monitoring each transmitter channel, four independently controlled receivers, integrated synthesizers, and digital signal processing functions providing a complete transceiver solution. The device provides the performance demanded by cellular infrastructure applications, such as small cell base station radios, macro 3G/4G/5G systems, and massive multiple in/multiple out (MIMO) base stations.

• Macro base stations

• Massive MIMO

• Small cells

• Aerospace and Defense

• Communications

• JESD204 (FSM) Interface Linux Kernel Framework

• JESD204 Interface Framework

Please follow the link here for detailed options and examples:

• ADRV9026/ADRV9029 Device Driver Customization

A stream processor is a processor within the transceiver tasked with performing a series of configuration tasks based on some event. After a request from the user, the stream processor performs a series of predefined actions that are loaded into the stream processor duringdevice initialization. This processor takes full advantage of the speed of the internal register buses for efficient execution of commands.

The stream processor can access and modify registers independently, avoiding the need for ARM interaction.

The stream processor executes streams, or series of tasks, for the following:

• Tx1/Tx2/Tx3/Tx4 enable/disable

• Rx1/Rx2/Rx3/Rx4 enable/disable

• ORx1/ORx2/ORx3/ORx4 enable/disable

The transceiver flexibility is maintained by implementing the stream processors with similar flexibility. The stream processor image changes with configuration, similar to how the initialization structures change with the selected profiles. For example, the stream thatenables the receivers differs depending on the JESD204B and JESD204C interface configuration. For this reason, it is necessary to save a stream image for each device configuration. When the user saves the configuration files (.c) using the GUI, a stream binary image isgenerated automatically. Use this stream file when initializing the transceiver with the profile in question.

The following are examples of how the stream files can differ:

• The framer choices for observation receiver and receiver

• For link sharing purposes

• If floating point formatting is being used on receiver and observation receiver paths, the stream image can change

Eleven separate stream processors exist in the transceiver, which are each responsible for the execution of some dedicated functionality within the device. These stream processors can be divided into two broad categories, slice stream processors and the core stream processor.

The stream binary stream_image_XYZ.bin must be stored in the /lib/firmware folder, or compiled into the kernel using the CONFIG_FIRMWARE_IN_KERNEL, CONFIG_EXTRA_FIRMWARE config options. Multiple stream binaries can be added. However a unique name must be given. The stream binary loaded during driver probe can be specified using following device tree property:

stream-firmware-name = “stream_image_6E3E00EFB74FE7D465FA88A171B81B8F.bin”;

In case no stream is specified or loaded, the driver will continue to use the standard stream_image_6E3E00EFB74FE7D465FA88A171B81B8F.bin file.

The transceiver is equipped with a built in ARM M4 processor. The firmware for this ARM processor is loaded during the initialization process. The firmware memory size is 224 kB, and the ARM has access to another 160 kB of data memory to utilize. The ARM is taskedwith configuring the transceiver for the selected use case, performing initial calibrations of the signal paths, and maintaining device performance over time through tracking calibrations.

When the arm core is powered up, the ARM moves into its power-up/reset state. The ARM firmware image is loaded at this point. When the ARM image has been loaded, the ARM is enabled and begins its boot sequence. After the arm has been booted, it enters its ready/idle state. In this state, it can receive configuration settings or commands (instructions), such as performing the initial calibrations or enabling tracking calibrations.

There is a dual core embedded ARM processor in which the DPD and CLGC algorithms reside. One of the dual core ARM processors is a control processor (ARM-C), which is the master, and the second core is a dedicated ARM core for DPD processing (ARM-D).

The firmware files for these processors must be stored in the /lib/firmware folder, or compiled into the kernel using the CONFIG_FIRMWARE_IN_KERNEL, CONFIG_EXTRA_FIRMWARE config options. The fimware loaded during driver probe are specified using following device tree property:

arm-firmware-name = “ADRV9025_FW.bin;ADRV9025_DPDCORE_FW.bin”;

The Gain tables for the RX and TX paths must also be loaded during boot/setup phase. They are also loaded using the firmware framework.

Configure kernel with “make menuconfig” (alternatively use “make xconfig” or “make qconfig”).

The ADRV9025 driver depends on CONFIG_SPI

Configure kernel with “make menuconfig” (alternatively use “make xconfig” or“make qconfig”)

Linux Kernel ConfigurationDevice Drivers ---><*> Industrial I/O support ---> --- Industrial I/O support -*- Enable ring buffer support within IIO -*- Industrial I/O lock free software ring -*- Enable triggered sampling support *** Analog to digital converters *** [--snip--]-*- Analog Devices High-Speed AXI ADC driver core< > Analog Devices AD9361, AD9364 RF Agile Transceiver driver< > Analog Devices AD9371 RF Transceiver driver< > Analog Devices ADRV9009/ADRV9008 RF Transceiver driver<*> Analog Devices ADRV9025/ADRV9026/ADRV9029 RF Transceiver driver< > Analog Devices AD6676 Wideband IF Receiver driver< > Analog Devices AD9467, AD9680, etc. high speed ADCs< > Analog Devices Motor Control (AD-FMCMOTCON) drivers [--snip--] Frequency Synthesizers DDS/PLL ---> Direct Digital Synthesis ---> <*> Analog Devices CoreFPGA AXI DDS driverClock Generator/Distribution --->< > Analog Devices AD9508 Clock Fanout Buffer < > Analog Devices AD9523 Low Jitter Clock Generator <*> Analog Devices AD9528 Low Jitter Clock Generator < > Analog Devices AD9548 Network Clock Generator/Synchronizer< > Analog Devices AD9517 12-Output Clock Generator <*> JESD204 High-Speed Serial Interface Support --->--- JESD204 High-Speed Serial Interface Support < > Altera Arria10 JESD204 PHY Support <*> Analog Devices AXI ADXCVR PHY Support < > Generic AXI JESD204B configuration driver <*> Analog Devices AXI JESD204B TX Support <*> Analog Devices AXI JESD204B RX Support 

Each and every IIO device, typically a hardware chip, has a device folder under /sys/bus/iio/devices/iio:deviceX.Where X is the IIO index of the device. Under every of these directory folders reside a set of files, depending on the characteristics and features of the hardware device in question. These files are consistently generalized and documented in the IIO ABI documentation. In order to determine which IIO deviceX corresponds to which hardware device, the user can read the name file /sys/bus/iio/devices/iio:deviceX/name. In case the sequence in which the iio device drivers are loaded/registered is constant, the numbering is constant and may be known in advance.

02 Mar 2011 15:16

General attribute naming convention:

root@analog:~# cd /sys/bus/iio/devices/root@analog:/sys/bus/iio/devices# lsiio:device0 iio:device2 iio:device4iio:device1 iio:device3 iio_sysfs_triggerroot@analog:/sys/bus/iio/devices# cd iio:device2root@analog:/sys/bus/iio/devices/iio:device2# ls -altotal 0drwxr-xr-x 3 root root 0 Nov 22 11:04 .drwxr-xr-x 6 root root 0 Nov 22 11:04 ..-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_rx_qec_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_lol_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_lol_ext_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_qec_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_temp0_input-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_gain_control_mode-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_gain_control_mode_available-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_hd2_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_rssi-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_gain_control_mode-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_gain_control_mode_available-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_hd2_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_rssi-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_gain_control_mode-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_gain_control_mode_available-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_hd2_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_rssi-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_gain_control_mode-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_gain_control_mode_available-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_hd2_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_rssi-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage_sampling_frequency-rw-r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_ctrl-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_error-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_paused--w------- 1 root root 4096 Nov 22 11:04 jesd204_fsm_resume-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_state-r--r--r-- 1 root root 4096 Nov 22 11:04 namelrwxrwxrwx 1 root root 0 Nov 22 11:04 of_node -> ../../../../../../../../firmware/devicetree/base/axi/spi@ff040000/adrv9025-phy@0-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage0_LO1_frequency-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage0_LO1_label-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage1_LO2_frequency-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage1_LO2_label-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage2_AUX_LO_frequency-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage2_AUX_LO_label-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_lo_leakage_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_lo_leakage_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_lo_leakage_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_lo_leakage_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage_sampling_frequencydrwxr-xr-x 2 root root 0 Nov 22 11:04 powerlrwxrwxrwx 1 root root 0 Nov 22 11:04 subsystem -> ../../../../../../../../bus/iio-rw-r--r-- 1 root root 4096 Nov 22 11:04 uevent-r--r--r-- 1 root root 4096 Nov 22 11:04 waiting_for_supplierroot@analog:/sys/bus/iio/devices/iio:device2# 

For use cases where pin control mode is not used or required, these attributes can be used to enable/disable the Rx/Tx signal paths while in the ENSM radio_on state.

• in_voltage0_en

• in_voltage1_en

• in_voltage2_en

• in_voltage3_en

• out_voltage0_en

• out_voltage1_en

• out_voltage2_en

• out_voltage3_en

root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage0_en 1root@analog:/sys/bus/iio/devices/iio:device2# echo 0 > in_voltage0_enroot@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage0_en 0

The device contains two RF PLLs. Each RF PLL uses the PLL block common to all synthesizers in the device and employ a 4 core VCO block which provides a 6dB phase noise improvement over the single core VCO. The tuneable range of the RF LO is 30-6000 MHz.It is possible to set the LO frequency independently for each port.

cat out_altvoltage2_AUX_LO_frequency 3605000000root@analog:/sys/bus/iio/devices/iio:device2# echo 3600000000 > out_altvoltage2_AUX_LO_frequency root@analog:/sys/bus/iio/devices/iio:device2# cat out_altvoltage2_AUX_LO_frequency 3600000000

Some care is needed for correctly handle carrier configuration. Note that the driver exposes 4 controls giving the idea that we can, independently, control all 4 ports. That is not true because, as stated above, the device only has 2 PLLs. Hence, applications have to be careful. For an example on how this can be handled and for more details, look at this commit on the IIO Oscilloscope plugin.

The ADRV9026 transmitter section consists of four identical and independently controlled channels that provide all the digital processing, mixed-signal, and RF blocks necessary toimplement a direct conversion system while sharing a common frequency synthesizer. The digital data from the SERDES lanes pass through a digital processing block that includes a series of programmable half-band filters, interpolation stages, and FIR filters, including a programmable FIR filter with variable interpolation rates and up to 80 taps. The output of this digital chain is connected to the digital-to-analog converter (DAC). The DAC sample rate is adjustable up to 2.5 GHz. The in-phase (I) and quadrature (Q) channels are identical in each transmitter signal chain.

After conversion to baseband analog signals, the I and Q signals are filtered to remove sampling artifacts and fed to the upconversion mixers. Each transmit chain provides a wide attenuation adjustment range with fine granularity to help designers optimize signal-to-noise ratio (SNR).

The following settings are available for each TX channel:

root@analog:/sys/bus/iio/devices/iio:device2# ls -la | grep out_voltage0-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_en-rw-r--r-- 1 root root 4096 Nov 22 15:25 out_voltage0_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_lo_leakage_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_rf_bandwidth

To query TX Primary Signal Bandwidth:

root@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_rf_bandwidth 450000000

To query and modify TX Hardware Gain:

root@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_hardwaregain -10.000000 dBroot@analog:/sys/bus/iio/devices/iio:device2# echo -12 > out_voltage0_hardwaregainroot@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_hardwaregain -12.000000 dB

The ADRV9026 provides four independent receiver channels. Each channel contains all the blocks necessary to receive RF signals and convert these signals to digital data usable by abaseband processor. Each receiver can be configured as a direct conversion system that supports up to a bandwidth of 200 MHz. Each channel contains a programmable attenuator stage, followed by matched I and Q mixers that downconvert received signals to baseband for digitization.

Two gain control options are available, as follows:

• Users can implement their own gain control algorithms using their baseband processor to manage manual gain control mode

• Users can use the on-chip automatic gain control (AGC) system.

Performance is optimized by mapping each gain control setting to specific attenuation levels at each adjustable gain block in the receive signal path. Additionally, each channel contains independent receive signal strength indication (RSSI) measurement capability, dc offset tracking, and all the circuitry necessary for self calibration.

The receivers include analog-to-digital converters (ADCs) and adjustable sample rates that produce data streams from the received signals. The signals can be conditioned further by aseries of decimation filters and a programmable FIR filter with additional decimation settings. The sample rate of each digital filter block is adjustable by changing decimation factors to produce the desired output data rate. All receiver outputs are connected to the SERDES block, where the data is formatted and serialized for transmission to the baseband processor.

The following settings are available for each RX channel:

ls -la | grep in_voltage1 -rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_bb_dc_offset_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_gain_control_mode-r--r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_gain_control_mode_available-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_hardwaregain-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_hd2_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_quadrature_tracking_en-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_rf_bandwidth-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_rssi

Through these controls, the user can run and configure BIST tests. In order to identify if the IIO device in question (adrv9025-phy) you first need to identify the IIO device number. Therefore read the name attribute of each IIO device

root@analog:~# grep "" /sys/bus/iio/devices/iio\:device*/name/sys/bus/iio/devices/iio:device0/name:xilinx-ams/sys/bus/iio/devices/iio:device1/name:ad9528-1/sys/bus/iio/devices/iio:device2/name:adrv9025-phy/sys/bus/iio/devices/iio:device3/name:axi-adrv9025-rx-hpc/sys/bus/iio/devices/iio:device4/name:axi-adrv9025-tx-hpc

Change directory to /sys/kernel/debug/iio/ iio:deviceX.

root@analog:~# cd /sys/kernel/debug/iio/iio\:device2root@analog:/sys/kernel/debug/iio/iio:device2# ls -latotal 0drwxr-xr-x 2 root root 0 Jul 10 2019 .drwxr-xr-x 6 root root 0 Jan 1 1970 ..-rw-r--r-- 1 root root 0 Jul 10 2019 bist_framer_0_prbs-rw-r--r-- 1 root root 0 Jul 10 2019 bist_framer_loopback-rw-r--r-- 1 root root 0 Jul 10 2019 bist_tone-rw-r--r-- 1 root root 0 Jul 10 2019 direct_reg_accessroot@analog:/sys/kernel/debug/iio/iio:device2#

Pseudorandom Binary Sequence (PRBS) to Framer 0.

SYNTAX:

bist_framer_0_prbs <Data Source>

Example: Inject ramp PRBS

root@analog:/sys/kernel/debug/iio/iio:device2# echo 8 > bist_framer_0_prbs 

Allows to digitally loopback framer data into the deframer.

SYNTAX:

bist_framer_loopback <Mode>

Example: Digital TX → Digital RX

root@analog:/sys/kernel/debug/iio/iio:device2# echo 1 > bist_framer_loopback 

User selectable tone (with frequency and gain selection), that can be injected into the TX path.All Tx channels are selected.

SYNTAX:

bist_tone <Enable> <Tone Frequency> <Tone Gain>

Example: Inject 0 dB tone at 3 MHz into TX (all channels enabled)

root@analog:/sys/kernel/debug/iio/iio:device2# echo 1 3000 > bist_tone 

root@analog:~# grep "" /sys/bus/iio/devices/iio\:device*/name/sys/bus/iio/devices/iio:device0/name:ad7291/sys/bus/iio/devices/iio:device1/name:ad9361-phy/sys/bus/iio/devices/iio:device2/name:xadc/sys/bus/iio/devices/iio:device3/name:adf4351-udc-rx-pmod/sys/bus/iio/devices/iio:device4/name:adf4351-udc-tx-pmod/sys/bus/iio/devices/iio:device5/name:cf-ad9361-dds-core-lpc/sys/bus/iio/devices/iio:device6/name:cf-ad9361-lpcroot@analog:~# 

root@analog:~# cd /sys/kernel/debug/iio/iio\:device1root@analog:/sys/kernel/debug/iio/iio:device1# ls direct_reg_access direct_reg_access

root@analog:/sys/kernel/debug/iio/iio:device1# echo 0x7 > direct_reg_access root@analog:/sys/kernel/debug/iio/iio:device1# cat direct_reg_access 0x40

root@analog:/sys/kernel/debug/iio/iio:device1# echo 0x7 0x50 > direct_reg_access root@analog:/sys/kernel/debug/iio/iio:device1# cat direct_reg_access 0x50

root@analog:/sys/kernel/debug/iio/iio:device6# echo 0x80000000 > direct_reg_access root@analog:/sys/kernel/debug/iio/iio:device6# cat direct_reg_access 0x80062

02 Mar 2011 15:16