Staging/fix orx channels madura#3402
Open
RaulGeo289 wants to merge 4 commits into
Open
Conversation
RaulGeo289
requested review from
CiprianRegus,
amiclaus,
btogorean,
buha,
chegbeli,
danmois,
dbogdan,
machschmitt,
mhennerich,
nunojsa,
rbolboac and
stefpopa
as code owners
June 26, 2026 11:21
Collaborator
Author
|
I think it would be appropriate to add a section in the driver documentation that addresses the change of mode from the profile, so the client knows he can use SPI mode, if he wants to. |
stefpopa
requested changes
Jun 26, 2026
stefpopa
left a comment
stefpopa
left a comment
Collaborator
There was a problem hiding this comment.
Be careful at the commit title style:
drivers: iio: → iio:, arch: arm64: xilinx: → arm64: dts: zynqmp-zcu102:
API cleanup should be separate — removing "OFF" from rf_port_select is a distinct change from the 4-pin GPIO feature
Collaborator
should be documented in github.io/wiki and as part of th DT bindings YAML |
RaulGeo289
force-pushed
the
staging/fix_ORX_channels_madura
branch
from
June 26, 2026 13:17
6b7f637 to
4dc3d1d
Compare
Collaborator
Author
|
Changelog v1: |
RaulGeo289
force-pushed
the
staging/fix_ORX_channels_madura
branch
from
June 26, 2026 13:34
4dc3d1d to
ea44e5d
Compare
gastmaier
reviewed
Jun 29, 2026
RaulGeo289
force-pushed
the
staging/fix_ORX_channels_madura
branch
2 times, most recently
from
June 30, 2026 12:03
2ee90a0 to
6e5d488
Compare
Collaborator
Author
|
Changelog V2: |
RaulGeo289
force-pushed
the
staging/fix_ORX_channels_madura
branch
from
July 1, 2026 11:57
6e5d488 to
e4b88d7
Compare
The dual-channel 4-pin ORx fix changes rf_port_select to a SELECT-only attribute with two items per pair (lower/upper ORx); the "OFF" entry no longer applies. Remove "OFF" from adrv9025_obs1_rx_port, adrv9025_obs2_rx_port and ad9371_obs_rx_port_lut, and have adrv9025_get_obs_rx_path parse the enable bits into the 2-item select index (upper bit => 1, else 0) so the readback always lands on a valid enum item. Signed-off-by: Georgian Raul <Raul.Georgian@analog.com>
Implement dual-channel 4-pin ORx mode (orxEnableMode=4). The ORx side enable and channel select are driven by the ORX_CTRL pins instead of the 0x106 SPI enable: A/C enable side-A/side-B, B/D select the ORx of each pair. Acquire the four optional orx-ctrl gpios at probe and add them to struct adrv9025_rf_phy. adrv9025_orx_dual_4pin() gates the new path on the gpios being wired and the cached init profile reporting orxEnableMode=4. In this mode rf_port_select becomes select-only (B/D pins) and _en drives the side enable (A/C pins) in read_raw/write_raw. The on-chip stream collapses the framer-1 ADC sample crossbar on every ORx enable edge, so adrv9025_orx_xbar_reassert() re-splits conv0/1 (side-A I/Q) and conv2/3 (side-B I/Q) after each enable/select change. Boards without the ORX_CTRL pins keep the legacy SPI select+enable path. Signed-off-by: Georgian Raul <Raul.Georgian@analog.com>
The dual -channel 4 pin mode uses 4 GPIO pins to control the enable and the selection of the ORX channels Signed-off-by: Georgian Raul <Raul.Georgian@analog.com>
Nodify the profile to use dual-channel 4 pin mode, instead of SPI mode by modifying the number of pins used from 0 to 4. Signed-off-by: Georgian Raul <Raul.Georgian@analog.com>
RaulGeo289
force-pushed
the
staging/fix_ORX_channels_madura
branch
from
July 1, 2026 12:33
e4b88d7 to
6eeb4c9
Compare
stefpopa
approved these changes
Jul 1, 2026
stefpopa
left a comment
stefpopa
left a comment
Collaborator
There was a problem hiding this comment.
- The PR title could be cleaner, for example:
iio: adc: adrv9025: add dual-channel 4-pin ORx GPIO mode - There is missing dt bindings documentation, but this can be added in a follow-up PR.
However, it looks good overall.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Description
There is a problem in IIO oscilloscope:
if i use 2 TXs using loopbacks to 2 ORXs and i enable them both,i can only
see on both ORXs only one TX.This usually happens when i enable the second
digital chennel first,then the first one.After this sequence,it looks like the SPI
mode can only control 1 digital channel.This isn't addressed in the user guide,
so it could be only a guess.And at the same time,following the enables for
the ORX channels in the 0x106 register,it looks like the stream processors
also modify the routing of the channels,so the write on the crossbar registers
is required.
The device tree change only selects the GPIO pins used for ORx control.
The profile switches the ORx enable mode from SPI mode to dual-channel
4-pin mode, where the ORx channels are controlled through GPIO pins
instead of the 0x106 SPI enable register.
In the driver, the enable functionality is removed from rf_port_select;
enable is now driven solely from in_voltage4_en (write_raw). So in
dual-channel 4-pin mode, enabling a channel just drives the GPIO pins
described in the user guide, based on the channel in use: CTRL_A enables
the first digital channel, CTRL_C the second.
On every ORx enable edge the on-chip stream processor alters the ADC
sample crossbar state, collapsing the dual-channel split. To keep the two
ORx channels routed to separate converters, the driver re-asserts the ADC
sample crossbar (with a mask) after the enable change. This crossbar
re-assert is a required part of the fix: without it, the stream processor
leaves both channels routed together. As described in the user guide:
"A stream processor ... performs a series of configuration tasks based
on some event. ... The stream processor executes streams ... for:
ORx1/ORx2/ORx3/ORx4 enable/disable."
In set_obs_rx_path(), the driver only sets the select pin: CTRL_B for the
first digital channel or CTRL_D for the second. The 'mode' value comes
from rf_port_select (set via IIO oscilloscope): 0 selects ORx2/ORx4,
1 selects the other two. So selection is purely a GPIO set through IIO.
PR Type
PR Checklist