.../bindings/iio/frequency/adi,ad9910.yaml | 236 +++ MAINTAINERS | 8 + drivers/iio/frequency/Kconfig | 18 + drivers/iio/frequency/Makefile | 1 + drivers/iio/frequency/ad9910.c | 2153 ++++++++++++++++++++ 5 files changed, 2416 insertions(+)
This patch series adds support for the Analog Devices AD9910 DDS.
This is an RFC so that we can agree/discuss on the design that follows:
The AD9910 DDS core can be driven through several independent mechanisms:
single tone profiles, a digital ramp generator, an internal RAM playback
engine, a parallel data port, and output shift keying. Each of these
represents a distinct signal path into the DDS accumulator, so the driver
models them as separate IIO output channels (all IIO_ALTVOLTAGE type).
This per-channel separation allows userspace to configure each mode
independently through its own set of sysfs attributes, and to
enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on
the hardware's own mode selection architecture.
The AD9910 register map is not suited for the regmap framework: register
widths vary across the map (16, 32, and 64 bits). The driver instead
implements direct SPI access helpers with a software register cache, using
type-specific read/write/update functions (ad9910_reg{16,32,64}_{read,
write,update}) that handle endianness conversion and cache coherency.
Registers are cached for several reasons. The control/function registers
(CFR1, CFR2) are frequently queried to determine the current operating
mode (e.g., checking RAM_ENABLE before every profile register access),
and caching avoids repeated SPI read transactions for what are
essentially state checks. The cache also enables efficient
read-modify-write updates on multi-byte registers: the update functions
merge new field values with the cached register content without issuing
a SPI read, and skip the write entirely when the value is unchanged.
Finally, the profile registers serve dual purposes depending on whether
RAM mode is active -- they hold single tone parameters (FTW, POW, ASF)
in normal operation but are repurposed for RAM playback configuration
(start/end address, step rate, operating mode) when RAM is enabled. A
shadow register array (reg_profile[]) preserves the inactive mode's
settings across transitions, so no state is lost when switching between
single tone and RAM operation.
RAM data is loaded through a write-only binary sysfs attribute
(ram_data). Userspace writes the waveform data as a raw binary buffer
(up to 4096 bytes for the full 1024x32-bit RAM), and the driver
transfers it to the device in a single SPI transaction. Per-profile
start/end addresses and playback parameters (operating mode, step rate,
no-dwell control) are configured through the RAM channel's ext_info
attributes.
Streaming data to the DDS core through the parallel data port at the
PD_CLK rate is not covered by this series. That functionality would
be added in a separate patch series, building on top of the IIO backend
infrastructure to provide a proper buffered data path.
As I am pushing implementation, as lot has been done already without much
supervision or agreement, still I would be interested on hearing about
the design choices discussed above. Here is the output for the iio_info
at this point:
5 channels found:
altvoltage1: (output)
9 channel-specific attributes found:
attr 0: en value: 0
attr 1: frequency_offset value: 0.000000
attr 2: frequency_scale value: 1
attr 3: label value: parallel_port
attr 4: phase_offset value: 0.000000
attr 5: powerdown value: 0
attr 6: profile value: 0
attr 7: sampling_frequency value: 100000000.000000
attr 8: scale_offset value: 0.000000
altvoltage3: (output)
13 channel-specific attributes found:
attr 0: address_end value: 1023
attr 1: address_start value: 0
attr 2: destination value: frequency
attr 3: destination_available value:
frequency phase amplitude polar
attr 4: en value: 0
attr 5: frequency value: 0.000000
attr 6: label value: ram_control
attr 7: operating_mode value: direct_switch
attr 8: operating_mode_available value:
direct_switch ramp_up bidirectional
bidirectional_continuous ramp_up_continuous
sequenced sequenced_continuous
attr 9: phase value: 0.000000
attr 10: powerdown value: 0
attr 11: profile value: 0
attr 12: sampling_frequency value: 100000000.000000
altvoltage2: (output)
27 channel-specific attributes found:
attr 0: burst_count value: 0
attr 1: burst_delay value: 0.000000030
attr 2: control_en value: 0
attr 3: decrement_sampling_frequency value: 100000000.000000
attr 4: destination value: frequency
attr 5: destination_available value: frequency phase amplitude
attr 6: en value: 0
attr 7: frequency_decrement value: 0.000000
attr 8: frequency_increment value: 0.000000
attr 9: frequency_max value: 0.000000
attr 10: frequency_min value: 0.000000
attr 11: increment_sampling_frequency value: 100000000.000000
attr 12: label value: digital_ramp_generator
attr 13: operating_mode value: bidirectional_continuous
attr 14: operating_mode_available value:
bidirectional ramp_down ramp_up bidirectional_continuous
attr 15: phase_decrement value: 0.000000000
attr 16: phase_increment value: 0.000000000
attr 17: phase_max value: 0.000000000
attr 18: phase_min value: 0.000000000
attr 19: powerdown value: 0
attr 20: profile value: 0
attr 21: ramp_delay value: 0.000000020
attr 22: scale_decrement value: 0.000000000
attr 23: scale_increment value: 0.000000000
attr 24: scale_max value: 0.000000000
attr 25: scale_min value: 0.000000000
attr 26: toggle_en value: 0
altvoltage0: (output)
6 channel-specific attributes found:
attr 0: frequency value: 0.000000
attr 1: label value: single_tone
attr 2: phase value: 0.000000
attr 3: powerdown value: 0
attr 4: profile value: 0
attr 5: scale value: 0.000000
altvoltage4: (output)
8 channel-specific attributes found:
attr 0: en value: 0
attr 1: label value: output_shift_keying
attr 2: pinctrl_en value: 0
attr 3: powerdown value: 0
attr 4: profile value: 0
attr 5: sampling_frequency value: 100000000.000000
attr 6: scale value: 0.000000
attr 7: scale_increment value: 0.000000
3 device-specific attributes found:
attr 0: ram_data ERROR: Permission denied (13)
attr 1: sysclk_frequency value: 400000000
attr 2: waiting_for_supplier value: 0
1 debug attributes found:
debug attr 0: direct_reg_access value: 0x2
Kind regards,
Rodrigo Alencar
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Rodrigo Alencar (8):
dt-bindings: iio: frequency: add ad9910
iio: frequency: ad9910: initial driver implementation
iio: frequency: ad9910: add simple parallel port mode support
iio: frequency: ad9910: expose sysclk_frequency device attribute
iio: frequency: ad9910: add digital ramp generator support
iio: frequency: ad9910: add RAM mode support
iio: frequency: ad9910: add output shift keying support
iio: frequency: ad9910: add channel labels
.../bindings/iio/frequency/adi,ad9910.yaml | 236 +++
MAINTAINERS | 8 +
drivers/iio/frequency/Kconfig | 18 +
drivers/iio/frequency/Makefile | 1 +
drivers/iio/frequency/ad9910.c | 2153 ++++++++++++++++++++
5 files changed, 2416 insertions(+)
---
base-commit: cce8de7f9744a210a4441ca8a667a9950515eea7
change-id: 20260218-ad9910-iio-driver-9b3d214c251f
Best regards,
--
Rodrigo Alencar <rodrigo.alencar@analog.com>
On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote:
> This patch series adds support for the Analog Devices AD9910 DDS.
> This is an RFC so that we can agree/discuss on the design that follows:
>
> The AD9910 DDS core can be driven through several independent mechanisms:
> single tone profiles, a digital ramp generator, an internal RAM playback
> engine, a parallel data port, and output shift keying. Each of these
This makes is sound more like a DAC than a frequency generator. altvoltage
specifically means an AC voltage (sine wave), so these arbitrary outputs
don't fit that.
> represents a distinct signal path into the DDS accumulator, so the driver
> models them as separate IIO output channels (all IIO_ALTVOLTAGE type).
Generally IIO channels represent the physical input/output, not the
internal channels.
Ideally we would just have the one channel here with a mode selection
attribute. Documentation can tell us which modes use which attributes.
> This per-channel separation allows userspace to configure each mode
> independently through its own set of sysfs attributes, and to
> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on
> the hardware's own mode selection architecture.
>
> The AD9910 register map is not suited for the regmap framework: register
> widths vary across the map (16, 32, and 64 bits). The driver instead
Does it break things if you read/write 64 bits from/to non-64-bit registers?
In other drivers for chips like this, we've just created 2 regmaps, i.e.
one for 16-bit regs and one for 32-bit regs. Seems better than
re-implementing a reg cache.
> implements direct SPI access helpers with a software register cache, using
> type-specific read/write/update functions (ad9910_reg{16,32,64}_{read,
> write,update}) that handle endianness conversion and cache coherency.
>
> Registers are cached for several reasons. The control/function registers
> (CFR1, CFR2) are frequently queried to determine the current operating
> mode (e.g., checking RAM_ENABLE before every profile register access),
> and caching avoids repeated SPI read transactions for what are
> essentially state checks. The cache also enables efficient
> read-modify-write updates on multi-byte registers: the update functions
> merge new field values with the cached register content without issuing
> a SPI read, and skip the write entirely when the value is unchanged.
> Finally, the profile registers serve dual purposes depending on whether
> RAM mode is active -- they hold single tone parameters (FTW, POW, ASF)
> in normal operation but are repurposed for RAM playback configuration
> (start/end address, step rate, operating mode) when RAM is enabled. A
> shadow register array (reg_profile[]) preserves the inactive mode's
> settings across transitions, so no state is lost when switching between
> single tone and RAM operation.
>
> RAM data is loaded through a write-only binary sysfs attribute
> (ram_data). Userspace writes the waveform data as a raw binary buffer
> (up to 4096 bytes for the full 1024x32-bit RAM), and the driver
> transfers it to the device in a single SPI transaction. Per-profile
> start/end addresses and playback parameters (operating mode, step rate,
> no-dwell control) are configured through the RAM channel's ext_info
> attributes.
>
> Streaming data to the DDS core through the parallel data port at the
> PD_CLK rate is not covered by this series. That functionality would
> be added in a separate patch series, building on top of the IIO backend
> infrastructure to provide a proper buffered data path.
>
> As I am pushing implementation, as lot has been done already without much
> supervision or agreement, still I would be interested on hearing about
> the design choices discussed above. Here is the output for the iio_info
> at this point:
>
> 5 channels found:
> altvoltage1: (output)
> 9 channel-specific attributes found:
> attr 0: en value: 0
> attr 1: frequency_offset value: 0.000000
> attr 2: frequency_scale value: 1
> attr 3: label value: parallel_port
> attr 4: phase_offset value: 0.000000
> attr 5: powerdown value: 0
> attr 6: profile value: 0
> attr 7: sampling_frequency value: 100000000.000000
> attr 8: scale_offset value: 0.000000
> altvoltage3: (output)
> 13 channel-specific attributes found:
> attr 0: address_end value: 1023
> attr 1: address_start value: 0
> attr 2: destination value: frequency
> attr 3: destination_available value:
> frequency phase amplitude polar
> attr 4: en value: 0
> attr 5: frequency value: 0.000000
> attr 6: label value: ram_control
> attr 7: operating_mode value: direct_switch
> attr 8: operating_mode_available value:
> direct_switch ramp_up bidirectional
> bidirectional_continuous ramp_up_continuous
> sequenced sequenced_continuous
> attr 9: phase value: 0.000000
> attr 10: powerdown value: 0
> attr 11: profile value: 0
> attr 12: sampling_frequency value: 100000000.000000
> altvoltage2: (output)
> 27 channel-specific attributes found:
> attr 0: burst_count value: 0
> attr 1: burst_delay value: 0.000000030
> attr 2: control_en value: 0
> attr 3: decrement_sampling_frequency value: 100000000.000000
> attr 4: destination value: frequency
> attr 5: destination_available value: frequency phase amplitude
> attr 6: en value: 0
> attr 7: frequency_decrement value: 0.000000
> attr 8: frequency_increment value: 0.000000
> attr 9: frequency_max value: 0.000000
> attr 10: frequency_min value: 0.000000
> attr 11: increment_sampling_frequency value: 100000000.000000
> attr 12: label value: digital_ramp_generator
> attr 13: operating_mode value: bidirectional_continuous
> attr 14: operating_mode_available value:
> bidirectional ramp_down ramp_up bidirectional_continuous
> attr 15: phase_decrement value: 0.000000000
> attr 16: phase_increment value: 0.000000000
> attr 17: phase_max value: 0.000000000
> attr 18: phase_min value: 0.000000000
> attr 19: powerdown value: 0
> attr 20: profile value: 0
> attr 21: ramp_delay value: 0.000000020
> attr 22: scale_decrement value: 0.000000000
> attr 23: scale_increment value: 0.000000000
> attr 24: scale_max value: 0.000000000
> attr 25: scale_min value: 0.000000000
> attr 26: toggle_en value: 0
> altvoltage0: (output)
> 6 channel-specific attributes found:
> attr 0: frequency value: 0.000000
> attr 1: label value: single_tone
> attr 2: phase value: 0.000000
> attr 3: powerdown value: 0
> attr 4: profile value: 0
> attr 5: scale value: 0.000000
> altvoltage4: (output)
> 8 channel-specific attributes found:
> attr 0: en value: 0
> attr 1: label value: output_shift_keying
> attr 2: pinctrl_en value: 0
> attr 3: powerdown value: 0
> attr 4: profile value: 0
> attr 5: sampling_frequency value: 100000000.000000
> attr 6: scale value: 0.000000
> attr 7: scale_increment value: 0.000000
> 3 device-specific attributes found:
> attr 0: ram_data ERROR: Permission denied (13)
> attr 1: sysclk_frequency value: 400000000
> attr 2: waiting_for_supplier value: 0
> 1 debug attributes found:
> debug attr 0: direct_reg_access value: 0x2
This is a lot of custom attributes!
It looks like a lot of these are just exposing registers directly, which
usually isn't the best if we want something that can be reused. However,
this looks pretty complex so coming up with something generic is probably
not worth the effort.
Instead, I would suggest to create a firmware file format that
describes how the chip should be programmed. And in the driver call
firmware_upload_register() to create a sysfs interface where the
firmware can be loaded/replaced at runtime. This way, there is just
one attribute write needed to set all of the parameters at once.
This could probably be as simple as something that just contains
the value of each register to be programmed and the driver can
write all of the registers just before enabling the output.
>
> Kind regards,
>
> Rodrigo Alencar
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> Rodrigo Alencar (8):
> dt-bindings: iio: frequency: add ad9910
> iio: frequency: ad9910: initial driver implementation
> iio: frequency: ad9910: add simple parallel port mode support
> iio: frequency: ad9910: expose sysclk_frequency device attribute
> iio: frequency: ad9910: add digital ramp generator support
> iio: frequency: ad9910: add RAM mode support
> iio: frequency: ad9910: add output shift keying support
> iio: frequency: ad9910: add channel labels
>
> .../bindings/iio/frequency/adi,ad9910.yaml | 236 +++
> MAINTAINERS | 8 +
> drivers/iio/frequency/Kconfig | 18 +
> drivers/iio/frequency/Makefile | 1 +
> drivers/iio/frequency/ad9910.c | 2153 ++++++++++++++++++++
> 5 files changed, 2416 insertions(+)
> ---
> base-commit: cce8de7f9744a210a4441ca8a667a9950515eea7
> change-id: 20260218-ad9910-iio-driver-9b3d214c251f
>
> Best regards,
On 26/02/21 02:16PM, David Lechner wrote:
> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote:
> > This patch series adds support for the Analog Devices AD9910 DDS.
> > This is an RFC so that we can agree/discuss on the design that follows:
> >
> > The AD9910 DDS core can be driven through several independent mechanisms:
> > single tone profiles, a digital ramp generator, an internal RAM playback
> > engine, a parallel data port, and output shift keying. Each of these
>
> This makes is sound more like a DAC than a frequency generator. altvoltage
> specifically means an AC voltage (sine wave), so these arbitrary outputs
> don't fit that.
Most applications for this part are in fact for frequency generation, like:
- Agile local oscillator (LO) frequency synthesis
- Programmable clock generators
- FM chirp source for radar and scanning systems
- Fast frequency hopping
The device has been made to be too flexible, so that its operation modes
have sub-operation modes that allows to handle frequency, scale and phase.
But at a specific timestamp, the output signal will always be a CW, i.e.
a sine or cosine wave.
> > represents a distinct signal path into the DDS accumulator, so the driver
> > models them as separate IIO output channels (all IIO_ALTVOLTAGE type).
>
> Generally IIO channels represent the physical input/output, not the
> internal channels.
That is part of the reason for this RFC. Dividing those top-level modes
into channels allows for better organization, as they can operate together,
i.e., phase or scale can be provided by single-tone profile, while
frequency is controlled by the digital ramp generator (see Mode Priority
section in the datasheet). Also, it allows to explore the most of standard
ABIs like, scale, frequency, phase, sampling_frequency and enable.
Putting everything into a single channel would make things a lot messy
to interface with.
> Ideally we would just have the one channel here with a mode selection
> attribute. Documentation can tell us which modes use which attributes.
>
> > This per-channel separation allows userspace to configure each mode
> > independently through its own set of sysfs attributes, and to
> > enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on
> > the hardware's own mode selection architecture.
> >
> > The AD9910 register map is not suited for the regmap framework: register
> > widths vary across the map (16, 32, and 64 bits). The driver instead
>
> Does it break things if you read/write 64 bits from/to non-64-bit registers?
Yes, the exact amount of bytes needs to be sent when writing specific registers.
> In other drivers for chips like this, we've just created 2 regmaps, i.e.
> one for 16-bit regs and one for 32-bit regs. Seems better than
> re-implementing a reg cache.
I would have to have 3 configs, one of them for a single 16-bit register.
Also, regmap_spi does not seem to support 64-bit registers (maybe I am wrong).
Additionally, single tone modes and RAM control modes are profile based and
they share the same registers, so I suppose that having to control the
register cache manually would be beneficial to switch RAM mode ON/OFF.
I understand that the digital design of the chip is not one of the best,
and a lot of unneeded complications are pushed to be handled in software.
> > implements direct SPI access helpers with a software register cache, using
> > type-specific read/write/update functions (ad9910_reg{16,32,64}_{read,
> > write,update}) that handle endianness conversion and cache coherency.
> >
> > Registers are cached for several reasons. The control/function registers
> > (CFR1, CFR2) are frequently queried to determine the current operating
> > mode (e.g., checking RAM_ENABLE before every profile register access),
> > and caching avoids repeated SPI read transactions for what are
> > essentially state checks. The cache also enables efficient
> > read-modify-write updates on multi-byte registers: the update functions
> > merge new field values with the cached register content without issuing
> > a SPI read, and skip the write entirely when the value is unchanged.
> > Finally, the profile registers serve dual purposes depending on whether
> > RAM mode is active -- they hold single tone parameters (FTW, POW, ASF)
> > in normal operation but are repurposed for RAM playback configuration
> > (start/end address, step rate, operating mode) when RAM is enabled. A
> > shadow register array (reg_profile[]) preserves the inactive mode's
> > settings across transitions, so no state is lost when switching between
> > single tone and RAM operation.
> >
> > RAM data is loaded through a write-only binary sysfs attribute
> > (ram_data). Userspace writes the waveform data as a raw binary buffer
> > (up to 4096 bytes for the full 1024x32-bit RAM), and the driver
> > transfers it to the device in a single SPI transaction. Per-profile
> > start/end addresses and playback parameters (operating mode, step rate,
> > no-dwell control) are configured through the RAM channel's ext_info
> > attributes.
> >
> > Streaming data to the DDS core through the parallel data port at the
> > PD_CLK rate is not covered by this series. That functionality would
> > be added in a separate patch series, building on top of the IIO backend
> > infrastructure to provide a proper buffered data path.
> >
> > As I am pushing implementation, as lot has been done already without much
> > supervision or agreement, still I would be interested on hearing about
> > the design choices discussed above. Here is the output for the iio_info
> > at this point:
> >
> > 5 channels found:
> > altvoltage1: (output)
> > 9 channel-specific attributes found:
> > attr 0: en value: 0
> > attr 1: frequency_offset value: 0.000000
> > attr 2: frequency_scale value: 1
> > attr 3: label value: parallel_port
> > attr 4: phase_offset value: 0.000000
> > attr 7: sampling_frequency value: 100000000.000000
> > attr 8: scale_offset value: 0.000000
> > altvoltage3: (output)
> > 13 channel-specific attributes found:
> > attr 0: address_end value: 1023
> > attr 1: address_start value: 0
> > attr 2: destination value: frequency
> > attr 3: destination_available value:
> > frequency phase amplitude polar
> > attr 4: en value: 0
> > attr 5: frequency value: 0.000000
> > attr 6: label value: ram_control
> > attr 7: operating_mode value: direct_switch
> > attr 8: operating_mode_available value:
> > direct_switch ramp_up bidirectional
> > bidirectional_continuous ramp_up_continuous
> > sequenced sequenced_continuous
> > attr 9: phase value: 0.000000
> > attr 12: sampling_frequency value: 100000000.000000
> > altvoltage2: (output)
> > 27 channel-specific attributes found:
> > attr 3: decrement_sampling_frequency value: 100000000.000000
> > attr 4: destination value: frequency
> > attr 5: destination_available value: frequency phase amplitude
> > attr 6: en value: 0
> > attr 7: frequency_decrement value: 0.000000
> > attr 8: frequency_increment value: 0.000000
> > attr 9: frequency_max value: 0.000000
> > attr 10: frequency_min value: 0.000000
> > attr 11: increment_sampling_frequency value: 100000000.000000
> > attr 12: label value: digital_ramp_generator
> > attr 13: operating_mode value: bidirectional_continuous
> > attr 14: operating_mode_available value:
> > bidirectional ramp_down ramp_up bidirectional_continuous
> > attr 15: phase_decrement value: 0.000000000
> > attr 16: phase_increment value: 0.000000000
> > attr 17: phase_max value: 0.000000000
> > attr 18: phase_min value: 0.000000000
> > attr 22: scale_decrement value: 0.000000000
> > attr 23: scale_increment value: 0.000000000
> > attr 24: scale_max value: 0.000000000
> > attr 25: scale_min value: 0.000000000
> > altvoltage0: (output)
> > 6 channel-specific attributes found:
> > attr 0: frequency value: 0.000000
> > attr 1: label value: single_tone
> > attr 2: phase value: 0.000000
> > attr 5: scale value: 0.000000
> > altvoltage4: (output)
> > 8 channel-specific attributes found:
> > attr 0: en value: 0
> > attr 1: label value: output_shift_keying
> > attr 2: pinctrl_en value: 0
> > attr 5: sampling_frequency value: 100000000.000000
> > attr 6: scale value: 0.000000
> > attr 7: scale_increment value: 0.000000
> > 3 device-specific attributes found:
> > attr 0: ram_data ERROR: Permission denied (13)
> > attr 1: sysclk_frequency value: 400000000
> > 1 debug attributes found:
> > debug attr 0: direct_reg_access value: 0x2
>
>
> This is a lot of custom attributes!
yes, specially for the digital ramp generator, where we have range
sets of increment, decrement, min and max for each DDS parameter:
scale, phase, frequency.
> It looks like a lot of these are just exposing registers directly, which
> usually isn't the best if we want something that can be reused. However,
> this looks pretty complex so coming up with something generic is probably
> not worth the effort.
Not directly, there is often a conversion whenever we are dealing
with scale, phase, frequency or sampling frequency.
> Instead, I would suggest to create a firmware file format that
> describes how the chip should be programmed. And in the driver call
> firmware_upload_register() to create a sysfs interface where the
> firmware can be loaded/replaced at runtime. This way, there is just
> one attribute write needed to set all of the parameters at once.
>
> This could probably be as simple as something that just contains
> the value of each register to be programmed and the driver can
> write all of the registers just before enabling the output.
Not sure, if that makes things simpler, specially for the application
the would interface with this. I think having the attributes as is
would be the whole point of using the IIO subsystem.
--
Kind regards,
Rodrigo Alencar
On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > On 26/02/21 02:16PM, David Lechner wrote: >> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: >>> This patch series adds support for the Analog Devices AD9910 DDS. >>> This is an RFC so that we can agree/discuss on the design that follows: >>> ... >>> represents a distinct signal path into the DDS accumulator, so the driver >>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). >> >> Generally IIO channels represent the physical input/output, not the >> internal channels. > > That is part of the reason for this RFC. Dividing those top-level modes > into channels allows for better organization, as they can operate together, > i.e., phase or scale can be provided by single-tone profile, while > frequency is controlled by the digital ramp generator (see Mode Priority > section in the datasheet). Also, it allows to explore the most of standard > ABIs like, scale, frequency, phase, sampling_frequency and enable. > Putting everything into a single channel would make things a lot messy > to interface with. > >> Ideally we would just have the one channel here with a mode selection >> attribute. Documentation can tell us which modes use which attributes. >> >>> This per-channel separation allows userspace to configure each mode >>> independently through its own set of sysfs attributes, and to >>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on >>> the hardware's own mode selection architecture. >>> Looking at Table 5 in the datasheet really helped me understand this better. I think this series could benefit from a documentation patch that explains more about how the driver works with some diagrams. So really what we have here are a bunch of digital data generators rather than a bunch of altvotlage output channels. And the same data channels can be mixed and match as the source for up to 3 different components of the output (frequency, phase, amplitude) depending on the priority rules defined in Table 5. Digital data sources are really more like a buffer in IIO terms than a channel. And before we added the IIO backend stuff, there wasn't really any other digital data source/sink that I am aware of other than buffers (but there are certainly a lot of odd corners of IIO that I haven't explored yet, so maybe I missed some). In a recent discussion, the idea of possibly needing a way to provide some userspace interface to be able to tweak knobs of an IIO backend was also brought up. Putting those ideas together, I'm wondering if we need some new channel type or even a whole new interface (e.g. a new sysfs directory like buffers and events) for managing these digital data sources/sinks that are not an IIO buffer. I think we've seen enough of these already to know that things like a "tone generator" and a "ramp generator" are going to be common and could share some standard attributes.
On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > On 26/02/21 02:16PM, David Lechner wrote: > > > On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > > > This patch series adds support for the Analog Devices AD9910 DDS. > > > > This is an RFC so that we can agree/discuss on the design that follows: > > > > > > ... > > > > > represents a distinct signal path into the DDS accumulator, so the driver > > > > models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > > > > > Generally IIO channels represent the physical input/output, not the > > > internal channels. > > > > That is part of the reason for this RFC. Dividing those top-level modes > > into channels allows for better organization, as they can operate together, > > i.e., phase or scale can be provided by single-tone profile, while > > frequency is controlled by the digital ramp generator (see Mode Priority > > section in the datasheet). Also, it allows to explore the most of standard > > ABIs like, scale, frequency, phase, sampling_frequency and enable. > > Putting everything into a single channel would make things a lot messy > > to interface with. > > > > > Ideally we would just have the one channel here with a mode selection > > > attribute. Documentation can tell us which modes use which attributes. > > > > > > > This per-channel separation allows userspace to configure each mode > > > > independently through its own set of sysfs attributes, and to > > > > enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > > > > the hardware's own mode selection architecture. > > > > > > Looking at Table 5 in the datasheet really helped me understand this better. > I think this series could benefit from a documentation patch that explains > more about how the driver works with some diagrams. > > So really what we have here are a bunch of digital data generators rather > than a bunch of altvotlage output channels. And the same data channels can be > mixed and match as the source for up to 3 different components of the output > (frequency, phase, amplitude) depending on the priority rules defined in > Table 5. More bellow... But note that all of the (or most of it) generators are going to be feed into a DAC. Your output is altvoltage but maybe we can treat the internals as voltage. Not sure. > > Digital data sources are really more like a buffer in IIO terms than a > channel. And before we added the IIO backend stuff, there wasn't really > any other digital data source/sink that I am aware of other than buffers > (but there are certainly a lot of odd corners of IIO that I haven't explored > yet, so maybe I missed some). > > In a recent discussion, the idea of possibly needing a way to provide > some userspace interface to be able to tweak knobs of an IIO backend > was also brought up. > > Putting those ideas together, I'm wondering if we need some new channel > type or even a whole new interface (e.g. a new sysfs directory like buffers > and events) for managing these digital data sources/sinks that are not an > IIO buffer. > But what would be that channel? In the end of the day, we typically have voltage or current DACs and a DDS primary function is indeed to generate alternating waveforms that you then typically feed into a DAC (and in some cases from the DAC into a power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure on the new type and I think we already have the "blocks" in IIO for dealing with this: . frequency . phase . amplitude (raw + scale + offset) But you're right that maybe it's time to think in a better way to fit them together. Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). And spoiler alert, as you might have guessed already, the parallel port stuff is to be used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo can confirm it. > I think we've seen enough of these already to know that things like a > "tone generator" and a "ramp generator" are going to be common and could > share some standard attributes. > I tend to agree. For example, there already some DACs (with dithering) that make use of a similar interface (but with a custom prefix). Though the end goal is different, the interface is not that far off: https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 Anyways, I knew this one would be an interesting one for upstream :) - Nuno Sá
On Mon, 23 Feb 2026 10:02:00 +0000 Nuno Sá <noname.nuno@gmail.com> wrote: > On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > > On 26/02/21 02:16PM, David Lechner wrote: > > > > On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > > > > This patch series adds support for the Analog Devices AD9910 DDS. > > > > > This is an RFC so that we can agree/discuss on the design that follows: > > > > > > > > > ... > > > > > > > represents a distinct signal path into the DDS accumulator, so the driver > > > > > models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > > > > > > > Generally IIO channels represent the physical input/output, not the > > > > internal channels. > > > > > > That is part of the reason for this RFC. Dividing those top-level modes > > > into channels allows for better organization, as they can operate together, > > > i.e., phase or scale can be provided by single-tone profile, while > > > frequency is controlled by the digital ramp generator (see Mode Priority > > > section in the datasheet). Also, it allows to explore the most of standard > > > ABIs like, scale, frequency, phase, sampling_frequency and enable. > > > Putting everything into a single channel would make things a lot messy > > > to interface with. > > > > > > > Ideally we would just have the one channel here with a mode selection > > > > attribute. Documentation can tell us which modes use which attributes. > > > > > > > > > This per-channel separation allows userspace to configure each mode > > > > > independently through its own set of sysfs attributes, and to > > > > > enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > > > > > the hardware's own mode selection architecture. > > > > > > > > > Looking at Table 5 in the datasheet really helped me understand this better. > > I think this series could benefit from a documentation patch that explains > > more about how the driver works with some diagrams. > > > > So really what we have here are a bunch of digital data generators rather > > than a bunch of altvotlage output channels. And the same data channels can be > > mixed and match as the source for up to 3 different components of the output > > (frequency, phase, amplitude) depending on the priority rules defined in > > Table 5. > > More bellow... But note that all of the (or most of it) generators are going to > be feed into a DAC. Your output is altvoltage but maybe we can treat the > internals as voltage. Not sure. > > > > > Digital data sources are really more like a buffer in IIO terms than a > > channel. And before we added the IIO backend stuff, there wasn't really > > any other digital data source/sink that I am aware of other than buffers > > (but there are certainly a lot of odd corners of IIO that I haven't explored > > yet, so maybe I missed some). > > > > In a recent discussion, the idea of possibly needing a way to provide > > some userspace interface to be able to tweak knobs of an IIO backend > > was also brought up. > > > > Putting those ideas together, I'm wondering if we need some new channel > > type or even a whole new interface (e.g. a new sysfs directory like buffers > > and events) for managing these digital data sources/sinks that are not an > > IIO buffer. > > > > But what would be that channel? In the end of the day, we typically have voltage or > current DACs and a DDS primary function is indeed to generate alternating waveforms > that you then typically feed into a DAC (and in some cases from the DAC into a > power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > on the new type and I think we already have the "blocks" in IIO for dealing with this: > > . frequency > . phase > . amplitude (raw + scale + offset) > > But you're right that maybe it's time to think in a better way to fit them together. > Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > > And spoiler alert, as you might have guessed already, the parallel port stuff is to be > used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > can confirm it. > > > I think we've seen enough of these already to know that things like a > > "tone generator" and a "ramp generator" are going to be common and could > > share some standard attributes. > > > > I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > interface (but with a custom prefix). Though the end goal is different, the interface is not that > far off: > > > https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > > Anyways, I knew this one would be an interesting one for upstream :) For history buffs, we had a bunch of DDS chips in staging at one point and never manage to figure out the questions being raised here :( They are complex beasts. Clarity of ABI proposal and documentation is going to be key to driving this series forwards. In a sense the code is the easy part. Jonathan > > - Nuno Sá >
On 26/03/01 01:38PM, Jonathan Cameron wrote: > On Mon, 23 Feb 2026 10:02:00 +0000 > Nuno Sá <noname.nuno@gmail.com> wrote: > > > On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > > On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > > > On 26/02/21 02:16PM, David Lechner wrote: > > > > > On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > > > > > This patch series adds support for the Analog Devices AD9910 DDS. > > > > > > This is an RFC so that we can agree/discuss on the design that follows: > > > > > > > > > > > > ... > > > > > > > > > represents a distinct signal path into the DDS accumulator, so the driver > > > > > > models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > > > > > > > > > Generally IIO channels represent the physical input/output, not the > > > > > internal channels. > > > > > > > > That is part of the reason for this RFC. Dividing those top-level modes > > > > into channels allows for better organization, as they can operate together, > > > > i.e., phase or scale can be provided by single-tone profile, while > > > > frequency is controlled by the digital ramp generator (see Mode Priority > > > > section in the datasheet). Also, it allows to explore the most of standard > > > > ABIs like, scale, frequency, phase, sampling_frequency and enable. > > > > Putting everything into a single channel would make things a lot messy > > > > to interface with. > > > > > > > > > Ideally we would just have the one channel here with a mode selection > > > > > attribute. Documentation can tell us which modes use which attributes. > > > > > > > > > > > This per-channel separation allows userspace to configure each mode > > > > > > independently through its own set of sysfs attributes, and to > > > > > > enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > > > > > > the hardware's own mode selection architecture. > > > > > > > > > > > > Looking at Table 5 in the datasheet really helped me understand this better. > > > I think this series could benefit from a documentation patch that explains > > > more about how the driver works with some diagrams. > > > > > > So really what we have here are a bunch of digital data generators rather > > > than a bunch of altvotlage output channels. And the same data channels can be > > > mixed and match as the source for up to 3 different components of the output > > > (frequency, phase, amplitude) depending on the priority rules defined in > > > Table 5. > > > > More bellow... But note that all of the (or most of it) generators are going to > > be feed into a DAC. Your output is altvoltage but maybe we can treat the > > internals as voltage. Not sure. > > > > > > > > Digital data sources are really more like a buffer in IIO terms than a > > > channel. And before we added the IIO backend stuff, there wasn't really > > > any other digital data source/sink that I am aware of other than buffers > > > (but there are certainly a lot of odd corners of IIO that I haven't explored > > > yet, so maybe I missed some). > > > > > > In a recent discussion, the idea of possibly needing a way to provide > > > some userspace interface to be able to tweak knobs of an IIO backend > > > was also brought up. > > > > > > Putting those ideas together, I'm wondering if we need some new channel > > > type or even a whole new interface (e.g. a new sysfs directory like buffers > > > and events) for managing these digital data sources/sinks that are not an > > > IIO buffer. > > > > > > > But what would be that channel? In the end of the day, we typically have voltage or > > current DACs and a DDS primary function is indeed to generate alternating waveforms > > that you then typically feed into a DAC (and in some cases from the DAC into a > > power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > > on the new type and I think we already have the "blocks" in IIO for dealing with this: > > > > . frequency > > . phase > > . amplitude (raw + scale + offset) > > > > But you're right that maybe it's time to think in a better way to fit them together. > > Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > > elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > > > > And spoiler alert, as you might have guessed already, the parallel port stuff is to be > > used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > > can confirm it. > > > > > I think we've seen enough of these already to know that things like a > > > "tone generator" and a "ramp generator" are going to be common and could > > > share some standard attributes. > > > > > > > I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > > interface (but with a custom prefix). Though the end goal is different, the interface is not that > > far off: > > > > > > https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > > > > Anyways, I knew this one would be an interesting one for upstream :) > > For history buffs, we had a bunch of DDS chips in staging at one point and never > manage to figure out the questions being raised here :( They are complex > beasts. Clarity of ABI proposal and documentation is going to be key to driving > this series forwards. In a sense the code is the easy part. Does that mean that once good documentation is provided, the presented design can be accepted? Even though data generators/sources might not be interpreted as altvoltage channels? -- Kind regards, Rodrigo Alencar
On Mon, 2 Mar 2026 10:22:47 +0000 Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > On 26/03/01 01:38PM, Jonathan Cameron wrote: > > On Mon, 23 Feb 2026 10:02:00 +0000 > > Nuno Sá <noname.nuno@gmail.com> wrote: > > > > > On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > > > On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > > > > On 26/02/21 02:16PM, David Lechner wrote: > > > > > > On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > > > > > > This patch series adds support for the Analog Devices AD9910 DDS. > > > > > > > This is an RFC so that we can agree/discuss on the design that follows: > > > > > > > > > > > > > > > ... > > > > > > > > > > > represents a distinct signal path into the DDS accumulator, so the driver > > > > > > > models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > > > > > > > > > > > Generally IIO channels represent the physical input/output, not the > > > > > > internal channels. > > > > > > > > > > That is part of the reason for this RFC. Dividing those top-level modes > > > > > into channels allows for better organization, as they can operate together, > > > > > i.e., phase or scale can be provided by single-tone profile, while > > > > > frequency is controlled by the digital ramp generator (see Mode Priority > > > > > section in the datasheet). Also, it allows to explore the most of standard > > > > > ABIs like, scale, frequency, phase, sampling_frequency and enable. > > > > > Putting everything into a single channel would make things a lot messy > > > > > to interface with. > > > > > > > > > > > Ideally we would just have the one channel here with a mode selection > > > > > > attribute. Documentation can tell us which modes use which attributes. > > > > > > > > > > > > > This per-channel separation allows userspace to configure each mode > > > > > > > independently through its own set of sysfs attributes, and to > > > > > > > enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > > > > > > > the hardware's own mode selection architecture. > > > > > > > > > > > > > > > Looking at Table 5 in the datasheet really helped me understand this better. > > > > I think this series could benefit from a documentation patch that explains > > > > more about how the driver works with some diagrams. > > > > > > > > So really what we have here are a bunch of digital data generators rather > > > > than a bunch of altvotlage output channels. And the same data channels can be > > > > mixed and match as the source for up to 3 different components of the output > > > > (frequency, phase, amplitude) depending on the priority rules defined in > > > > Table 5. > > > > > > More bellow... But note that all of the (or most of it) generators are going to > > > be feed into a DAC. Your output is altvoltage but maybe we can treat the > > > internals as voltage. Not sure. > > > > > > > > > > > Digital data sources are really more like a buffer in IIO terms than a > > > > channel. And before we added the IIO backend stuff, there wasn't really > > > > any other digital data source/sink that I am aware of other than buffers > > > > (but there are certainly a lot of odd corners of IIO that I haven't explored > > > > yet, so maybe I missed some). > > > > > > > > In a recent discussion, the idea of possibly needing a way to provide > > > > some userspace interface to be able to tweak knobs of an IIO backend > > > > was also brought up. > > > > > > > > Putting those ideas together, I'm wondering if we need some new channel > > > > type or even a whole new interface (e.g. a new sysfs directory like buffers > > > > and events) for managing these digital data sources/sinks that are not an > > > > IIO buffer. > > > > > > > > > > But what would be that channel? In the end of the day, we typically have voltage or > > > current DACs and a DDS primary function is indeed to generate alternating waveforms > > > that you then typically feed into a DAC (and in some cases from the DAC into a > > > power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > > > on the new type and I think we already have the "blocks" in IIO for dealing with this: > > > > > > . frequency > > > . phase > > > . amplitude (raw + scale + offset) > > > > > > But you're right that maybe it's time to think in a better way to fit them together. > > > Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > > > elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > > > > > > And spoiler alert, as you might have guessed already, the parallel port stuff is to be > > > used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > > > can confirm it. > > > > > > > I think we've seen enough of these already to know that things like a > > > > "tone generator" and a "ramp generator" are going to be common and could > > > > share some standard attributes. > > > > > > > > > > I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > > > interface (but with a custom prefix). Though the end goal is different, the interface is not that > > > far off: > > > > > > > > > https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > > > > > > Anyways, I knew this one would be an interesting one for upstream :) > > > > For history buffs, we had a bunch of DDS chips in staging at one point and never > > manage to figure out the questions being raised here :( They are complex > > beasts. Clarity of ABI proposal and documentation is going to be key to driving > > this series forwards. In a sense the code is the easy part. > > Does that mean that once good documentation is provided, the presented design can > be accepted? Even though data generators/sources might not be interpreted as > altvoltage channels? I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion on how to handle this channel 'mixing' case. If we did go this way, we'd need to figure out a way to describe the mixing part. So either we describe it as one channel (which is going to be really complex) or we describe it as multiple channels but add extra ABI to make it clear they are mixed into a single 'physical' channel. Jonathan >
On 3/7/26 8:09 AM, Jonathan Cameron wrote: > On Mon, 2 Mar 2026 10:22:47 +0000 > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > >> On 26/03/01 01:38PM, Jonathan Cameron wrote: >>> On Mon, 23 Feb 2026 10:02:00 +0000 >>> Nuno Sá <noname.nuno@gmail.com> wrote: >>> >>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: >>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: >>>>>> On 26/02/21 02:16PM, David Lechner wrote: >>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: >>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. >>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: >>>>>>>> >>>>> >>>>> ... >>>>> >>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver >>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). >>>>>>> >>>>>>> Generally IIO channels represent the physical input/output, not the >>>>>>> internal channels. >>>>>> >>>>>> That is part of the reason for this RFC. Dividing those top-level modes >>>>>> into channels allows for better organization, as they can operate together, >>>>>> i.e., phase or scale can be provided by single-tone profile, while >>>>>> frequency is controlled by the digital ramp generator (see Mode Priority >>>>>> section in the datasheet). Also, it allows to explore the most of standard >>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. >>>>>> Putting everything into a single channel would make things a lot messy >>>>>> to interface with. >>>>>> >>>>>>> Ideally we would just have the one channel here with a mode selection >>>>>>> attribute. Documentation can tell us which modes use which attributes. >>>>>>> >>>>>>>> This per-channel separation allows userspace to configure each mode >>>>>>>> independently through its own set of sysfs attributes, and to >>>>>>>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on >>>>>>>> the hardware's own mode selection architecture. >>>>>>>> >>>>> >>>>> Looking at Table 5 in the datasheet really helped me understand this better. >>>>> I think this series could benefit from a documentation patch that explains >>>>> more about how the driver works with some diagrams. >>>>> >>>>> So really what we have here are a bunch of digital data generators rather >>>>> than a bunch of altvotlage output channels. And the same data channels can be >>>>> mixed and match as the source for up to 3 different components of the output >>>>> (frequency, phase, amplitude) depending on the priority rules defined in >>>>> Table 5. >>>> >>>> More bellow... But note that all of the (or most of it) generators are going to >>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the >>>> internals as voltage. Not sure. >>>> >>>>> >>>>> Digital data sources are really more like a buffer in IIO terms than a >>>>> channel. And before we added the IIO backend stuff, there wasn't really >>>>> any other digital data source/sink that I am aware of other than buffers >>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored >>>>> yet, so maybe I missed some). >>>>> >>>>> In a recent discussion, the idea of possibly needing a way to provide >>>>> some userspace interface to be able to tweak knobs of an IIO backend >>>>> was also brought up. >>>>> >>>>> Putting those ideas together, I'm wondering if we need some new channel >>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers >>>>> and events) for managing these digital data sources/sinks that are not an >>>>> IIO buffer. >>>>> >>>> >>>> But what would be that channel? In the end of the day, we typically have voltage or >>>> current DACs and a DDS primary function is indeed to generate alternating waveforms >>>> that you then typically feed into a DAC (and in some cases from the DAC into a >>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure >>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: >>>> >>>> . frequency >>>> . phase >>>> . amplitude (raw + scale + offset) >>>> >>>> But you're right that maybe it's time to think in a better way to fit them together. >>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan >>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). >>>> >>>> And spoiler alert, as you might have guessed already, the parallel port stuff is to be >>>> used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo >>>> can confirm it. >>>> >>>>> I think we've seen enough of these already to know that things like a >>>>> "tone generator" and a "ramp generator" are going to be common and could >>>>> share some standard attributes. >>>>> >>>> >>>> I tend to agree. For example, there already some DACs (with dithering) that make use of a similar >>>> interface (but with a custom prefix). Though the end goal is different, the interface is not that >>>> far off: >>>> >>>> >>>> https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 >>>> >>>> Anyways, I knew this one would be an interesting one for upstream :) >>> >>> For history buffs, we had a bunch of DDS chips in staging at one point and never >>> manage to figure out the questions being raised here :( They are complex >>> beasts. Clarity of ABI proposal and documentation is going to be key to driving >>> this series forwards. In a sense the code is the easy part. >> >> Does that mean that once good documentation is provided, the presented design can >> be accepted? Even though data generators/sources might not be interpreted as >> altvoltage channels? > > I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion > on how to handle this channel 'mixing' case. > > If we did go this way, we'd need to figure out a way to describe the mixing part. > So either we describe it as one channel (which is going to be really complex) > or we describe it as multiple channels but add extra ABI to make it clear they > are mixed into a single 'physical' channel. > > Jonathan > >> > Some ideas have crossed my mind, like adding new option to the in_/out_ prefix for "internal" channels. But I it would take a long time to teach existing generic userspace libraries/tools about this. What has popped into my head just now is that perhaps we could do like Rodrigo is proposing here reusing existing channels and standard attributes as much as possible and add a new "subcomponent_of" attribute to provide the link, similar to "current_trigger" for triggers. This way, it would still work with existing userspace tools (even if it looks a bit confusing). And userspace tools could eventually be taught to present the channels as a tree-like structure with the main channel and subcomponents nested under it. We would want to spell out up front what all of the anticipated ways of using it are. For example, I suspect eventually someone will want this attribute to be writeable to assign a specific limited resource to a specific channel. An I expect that we would eventually see something were a single subcomponent is shared between multiple physical channels. In this case, we would want the value of the "subcomponent_of" attribute to be able to be a list.
On Sat, 7 Mar 2026 10:50:14 -0600 David Lechner <dlechner@baylibre.com> wrote: > On 3/7/26 8:09 AM, Jonathan Cameron wrote: > > On Mon, 2 Mar 2026 10:22:47 +0000 > > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > > > >> On 26/03/01 01:38PM, Jonathan Cameron wrote: > >>> On Mon, 23 Feb 2026 10:02:00 +0000 > >>> Nuno Sá <noname.nuno@gmail.com> wrote: > >>> > >>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > >>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > >>>>>> On 26/02/21 02:16PM, David Lechner wrote: > >>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > >>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. > >>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: > >>>>>>>> > >>>>> > >>>>> ... > >>>>> > >>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver > >>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > >>>>>>> > >>>>>>> Generally IIO channels represent the physical input/output, not the > >>>>>>> internal channels. > >>>>>> > >>>>>> That is part of the reason for this RFC. Dividing those top-level modes > >>>>>> into channels allows for better organization, as they can operate together, > >>>>>> i.e., phase or scale can be provided by single-tone profile, while > >>>>>> frequency is controlled by the digital ramp generator (see Mode Priority > >>>>>> section in the datasheet). Also, it allows to explore the most of standard > >>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. > >>>>>> Putting everything into a single channel would make things a lot messy > >>>>>> to interface with. > >>>>>> > >>>>>>> Ideally we would just have the one channel here with a mode selection > >>>>>>> attribute. Documentation can tell us which modes use which attributes. > >>>>>>> > >>>>>>>> This per-channel separation allows userspace to configure each mode > >>>>>>>> independently through its own set of sysfs attributes, and to > >>>>>>>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > >>>>>>>> the hardware's own mode selection architecture. > >>>>>>>> > >>>>> > >>>>> Looking at Table 5 in the datasheet really helped me understand this better. > >>>>> I think this series could benefit from a documentation patch that explains > >>>>> more about how the driver works with some diagrams. > >>>>> > >>>>> So really what we have here are a bunch of digital data generators rather > >>>>> than a bunch of altvotlage output channels. And the same data channels can be > >>>>> mixed and match as the source for up to 3 different components of the output > >>>>> (frequency, phase, amplitude) depending on the priority rules defined in > >>>>> Table 5. > >>>> > >>>> More bellow... But note that all of the (or most of it) generators are going to > >>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the > >>>> internals as voltage. Not sure. > >>>> > >>>>> > >>>>> Digital data sources are really more like a buffer in IIO terms than a > >>>>> channel. And before we added the IIO backend stuff, there wasn't really > >>>>> any other digital data source/sink that I am aware of other than buffers > >>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored > >>>>> yet, so maybe I missed some). > >>>>> > >>>>> In a recent discussion, the idea of possibly needing a way to provide > >>>>> some userspace interface to be able to tweak knobs of an IIO backend > >>>>> was also brought up. > >>>>> > >>>>> Putting those ideas together, I'm wondering if we need some new channel > >>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers > >>>>> and events) for managing these digital data sources/sinks that are not an > >>>>> IIO buffer. > >>>>> > >>>> > >>>> But what would be that channel? In the end of the day, we typically have voltage or > >>>> current DACs and a DDS primary function is indeed to generate alternating waveforms > >>>> that you then typically feed into a DAC (and in some cases from the DAC into a > >>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > >>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: > >>>> > >>>> . frequency > >>>> . phase > >>>> . amplitude (raw + scale + offset) > >>>> > >>>> But you're right that maybe it's time to think in a better way to fit them together. > >>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > >>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > >>>> > >>>> And spoiler alert, as you might have guessed already, the parallel port stuff is to be > >>>> used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > >>>> can confirm it. > >>>> > >>>>> I think we've seen enough of these already to know that things like a > >>>>> "tone generator" and a "ramp generator" are going to be common and could > >>>>> share some standard attributes. > >>>>> > >>>> > >>>> I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > >>>> interface (but with a custom prefix). Though the end goal is different, the interface is not that > >>>> far off: > >>>> > >>>> > >>>> https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > >>>> > >>>> Anyways, I knew this one would be an interesting one for upstream :) > >>> > >>> For history buffs, we had a bunch of DDS chips in staging at one point and never > >>> manage to figure out the questions being raised here :( They are complex > >>> beasts. Clarity of ABI proposal and documentation is going to be key to driving > >>> this series forwards. In a sense the code is the easy part. > >> > >> Does that mean that once good documentation is provided, the presented design can > >> be accepted? Even though data generators/sources might not be interpreted as > >> altvoltage channels? > > > > I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion > > on how to handle this channel 'mixing' case. > > > > If we did go this way, we'd need to figure out a way to describe the mixing part. > > So either we describe it as one channel (which is going to be really complex) > > or we describe it as multiple channels but add extra ABI to make it clear they > > are mixed into a single 'physical' channel. > > > > Jonathan > > > >> > > > > Some ideas have crossed my mind, like adding new option to the in_/out_ > prefix for "internal" channels. But I it would take a long time to teach > existing generic userspace libraries/tools about this. > > What has popped into my head just now is that perhaps we could do like > Rodrigo is proposing here reusing existing channels and standard attributes > as much as possible and add a new "subcomponent_of" attribute to provide > the link, similar to "current_trigger" for triggers. > > This way, it would still work with existing userspace tools (even if it > looks a bit confusing). And userspace tools could eventually be taught > to present the channels as a tree-like structure with the main channel > and subcomponents nested under it. > > We would want to spell out up front what all of the anticipated ways of > using it are. For example, I suspect eventually someone will want this > attribute to be writeable to assign a specific limited resource to a > specific channel. An I expect that we would eventually see something were > a single subcomponent is shared between multiple physical channels. In > this case, we would want the value of the "subcomponent_of" attribute to > be able to be a list. Something along those lines might work. I'd not thought about the case of one 'internal' going to multiple 'external'. Otherwise I was wondering if something informal related to labels would work. We've done that where we've been associating things like voltage and power measurement from a single pin. It's rather adhoc though. Possibly we could roll it into a newer more general scheme. If the association is done as meta data attributes alongside existing channels then as you say existing tools will kind of work, just need some human understanding of what is actually being controlled until they catch up with the newer schemes. Lots of ways we could actually represent the graphs. Going to take some figuring out! J
On 26/03/07 04:58PM, Jonathan Cameron wrote: > On Sat, 7 Mar 2026 10:50:14 -0600 > David Lechner <dlechner@baylibre.com> wrote: > > > On 3/7/26 8:09 AM, Jonathan Cameron wrote: > > > On Mon, 2 Mar 2026 10:22:47 +0000 > > > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > > > > > >> On 26/03/01 01:38PM, Jonathan Cameron wrote: > > >>> On Mon, 23 Feb 2026 10:02:00 +0000 > > >>> Nuno Sá <noname.nuno@gmail.com> wrote: > > >>> > > >>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > >>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > >>>>>> On 26/02/21 02:16PM, David Lechner wrote: > > >>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > >>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. > > >>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: > > >>>>>>>> > > >>>>> > > >>>>> ... > > >>>>> > > >>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver > > >>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > >>>>>>> > > >>>>>>> Generally IIO channels represent the physical input/output, not the > > >>>>>>> internal channels. > > >>>>>> > > >>>>>> That is part of the reason for this RFC. Dividing those top-level modes > > >>>>>> into channels allows for better organization, as they can operate together, > > >>>>>> i.e., phase or scale can be provided by single-tone profile, while > > >>>>>> frequency is controlled by the digital ramp generator (see Mode Priority > > >>>>>> section in the datasheet). Also, it allows to explore the most of standard > > >>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. > > >>>>>> Putting everything into a single channel would make things a lot messy > > >>>>>> to interface with. > > >>>>>> > > >>>>>>> Ideally we would just have the one channel here with a mode selection > > >>>>>>> attribute. Documentation can tell us which modes use which attributes. > > >>>>>>> > > >>>>>>>> This per-channel separation allows userspace to configure each mode > > >>>>>>>> independently through its own set of sysfs attributes, and to > > >>>>>>>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > > >>>>>>>> the hardware's own mode selection architecture. > > >>>>>>>> > > >>>>> > > >>>>> Looking at Table 5 in the datasheet really helped me understand this better. > > >>>>> I think this series could benefit from a documentation patch that explains > > >>>>> more about how the driver works with some diagrams. > > >>>>> > > >>>>> So really what we have here are a bunch of digital data generators rather > > >>>>> than a bunch of altvotlage output channels. And the same data channels can be > > >>>>> mixed and match as the source for up to 3 different components of the output > > >>>>> (frequency, phase, amplitude) depending on the priority rules defined in > > >>>>> Table 5. > > >>>> > > >>>> More bellow... But note that all of the (or most of it) generators are going to > > >>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the > > >>>> internals as voltage. Not sure. > > >>>> > > >>>>> > > >>>>> Digital data sources are really more like a buffer in IIO terms than a > > >>>>> channel. And before we added the IIO backend stuff, there wasn't really > > >>>>> any other digital data source/sink that I am aware of other than buffers > > >>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored > > >>>>> yet, so maybe I missed some). > > >>>>> > > >>>>> In a recent discussion, the idea of possibly needing a way to provide > > >>>>> some userspace interface to be able to tweak knobs of an IIO backend > > >>>>> was also brought up. > > >>>>> > > >>>>> Putting those ideas together, I'm wondering if we need some new channel > > >>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers > > >>>>> and events) for managing these digital data sources/sinks that are not an > > >>>>> IIO buffer. > > >>>>> > > >>>> > > >>>> But what would be that channel? In the end of the day, we typically have voltage or > > >>>> current DACs and a DDS primary function is indeed to generate alternating waveforms > > >>>> that you then typically feed into a DAC (and in some cases from the DAC into a > > >>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > > >>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: > > >>>> > > >>>> . frequency > > >>>> . phase > > >>>> . amplitude (raw + scale + offset) > > >>>> > > >>>> But you're right that maybe it's time to think in a better way to fit them together. > > >>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > > >>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > > >>>> > > >>>> And spoiler alert, as you might have guessed already, the parallel port stuff is to be > > >>>> used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > > >>>> can confirm it. > > >>>> > > >>>>> I think we've seen enough of these already to know that things like a > > >>>>> "tone generator" and a "ramp generator" are going to be common and could > > >>>>> share some standard attributes. > > >>>>> > > >>>> > > >>>> I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > > >>>> interface (but with a custom prefix). Though the end goal is different, the interface is not that > > >>>> far off: > > >>>> > > >>>> > > >>>> https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > > >>>> > > >>>> Anyways, I knew this one would be an interesting one for upstream :) > > >>> > > >>> For history buffs, we had a bunch of DDS chips in staging at one point and never > > >>> manage to figure out the questions being raised here :( They are complex > > >>> beasts. Clarity of ABI proposal and documentation is going to be key to driving > > >>> this series forwards. In a sense the code is the easy part. > > >> > > >> Does that mean that once good documentation is provided, the presented design can > > >> be accepted? Even though data generators/sources might not be interpreted as > > >> altvoltage channels? > > > > > > I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion > > > on how to handle this channel 'mixing' case. > > > > > > If we did go this way, we'd need to figure out a way to describe the mixing part. > > > So either we describe it as one channel (which is going to be really complex) > > > or we describe it as multiple channels but add extra ABI to make it clear they > > > are mixed into a single 'physical' channel. > > > > > > Jonathan > > > > > >> > > > > > > > Some ideas have crossed my mind, like adding new option to the in_/out_ > > prefix for "internal" channels. But I it would take a long time to teach > > existing generic userspace libraries/tools about this. > > > > What has popped into my head just now is that perhaps we could do like > > Rodrigo is proposing here reusing existing channels and standard attributes > > as much as possible and add a new "subcomponent_of" attribute to provide > > the link, similar to "current_trigger" for triggers. > > > > This way, it would still work with existing userspace tools (even if it > > looks a bit confusing). And userspace tools could eventually be taught > > to present the channels as a tree-like structure with the main channel > > and subcomponents nested under it. > > > > We would want to spell out up front what all of the anticipated ways of > > using it are. For example, I suspect eventually someone will want this > > attribute to be writeable to assign a specific limited resource to a > > specific channel. An I expect that we would eventually see something were > > a single subcomponent is shared between multiple physical channels. In > > this case, we would want the value of the "subcomponent_of" attribute to > > be able to be a list. > > Something along those lines might work. I'd not thought about the case > of one 'internal' going to multiple 'external'. Otherwise I was wondering > if something informal related to labels would work. We've done that where > we've been associating things like voltage and power measurement from a single > pin. It's rather adhoc though. Possibly we could roll it into a newer > more general scheme. > > If the association is done as meta data attributes alongside existing > channels then as you say existing tools will kind of work, just need some > human understanding of what is actually being controlled until they catch > up with the newer schemes. > > Lots of ways we could actually represent the graphs. Going to take some > figuring out! I like the idea of subchannels to create logical tree-structures. It opens up for other possibilities. I wonder if the varying channel index would still confuse a user, even with this metadata attribute, like: - out_altvoltage0 - out_altvoltage1 - out_altvoltage1_subcomponent_of = out_altvoltage0 would there be a different way to name the full_postfix in __iio_device_attr_init() that would allow to keep channel index the same (e.g. altvoltage0 for multiple internal sub-channel) and still be compatible with userspace tools? I don't know, something like: - out_altvoltage0 - out_altvoltage0_0 - out_altvoltage0_1 - out_altvoltage0_2 userspace tools would understand out_altvoltage0_0_frequency as: - direction: out - type: altvoltage - channel idx: 0 - attr name: 0_frequency and that would be a problem? -- Kind regards, Rodrigo Alencar
On 3/7/26 12:54 PM, Rodrigo Alencar wrote: > On 26/03/07 04:58PM, Jonathan Cameron wrote: >> On Sat, 7 Mar 2026 10:50:14 -0600 >> David Lechner <dlechner@baylibre.com> wrote: >> >>> On 3/7/26 8:09 AM, Jonathan Cameron wrote: >>>> On Mon, 2 Mar 2026 10:22:47 +0000 >>>> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: >>>> >>>>> On 26/03/01 01:38PM, Jonathan Cameron wrote: >>>>>> On Mon, 23 Feb 2026 10:02:00 +0000 >>>>>> Nuno Sá <noname.nuno@gmail.com> wrote: >>>>>> >>>>>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: >>>>>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: >>>>>>>>> On 26/02/21 02:16PM, David Lechner wrote: >>>>>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: >>>>>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. >>>>>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: >>>>>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver >>>>>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). >>>>>>>>>> >>>>>>>>>> Generally IIO channels represent the physical input/output, not the >>>>>>>>>> internal channels. >>>>>>>>> >>>>>>>>> That is part of the reason for this RFC. Dividing those top-level modes >>>>>>>>> into channels allows for better organization, as they can operate together, >>>>>>>>> i.e., phase or scale can be provided by single-tone profile, while >>>>>>>>> frequency is controlled by the digital ramp generator (see Mode Priority >>>>>>>>> section in the datasheet). Also, it allows to explore the most of standard >>>>>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. >>>>>>>>> Putting everything into a single channel would make things a lot messy >>>>>>>>> to interface with. >>>>>>>>> >>>>>>>>>> Ideally we would just have the one channel here with a mode selection >>>>>>>>>> attribute. Documentation can tell us which modes use which attributes. >>>>>>>>>> >>>>>>>>>>> This per-channel separation allows userspace to configure each mode >>>>>>>>>>> independently through its own set of sysfs attributes, and to >>>>>>>>>>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on >>>>>>>>>>> the hardware's own mode selection architecture. >>>>>>>>>>> >>>>>>>> >>>>>>>> Looking at Table 5 in the datasheet really helped me understand this better. >>>>>>>> I think this series could benefit from a documentation patch that explains >>>>>>>> more about how the driver works with some diagrams. >>>>>>>> >>>>>>>> So really what we have here are a bunch of digital data generators rather >>>>>>>> than a bunch of altvotlage output channels. And the same data channels can be >>>>>>>> mixed and match as the source for up to 3 different components of the output >>>>>>>> (frequency, phase, amplitude) depending on the priority rules defined in >>>>>>>> Table 5. >>>>>>> >>>>>>> More bellow... But note that all of the (or most of it) generators are going to >>>>>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the >>>>>>> internals as voltage. Not sure. >>>>>>> >>>>>>>> >>>>>>>> Digital data sources are really more like a buffer in IIO terms than a >>>>>>>> channel. And before we added the IIO backend stuff, there wasn't really >>>>>>>> any other digital data source/sink that I am aware of other than buffers >>>>>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored >>>>>>>> yet, so maybe I missed some). >>>>>>>> >>>>>>>> In a recent discussion, the idea of possibly needing a way to provide >>>>>>>> some userspace interface to be able to tweak knobs of an IIO backend >>>>>>>> was also brought up. >>>>>>>> >>>>>>>> Putting those ideas together, I'm wondering if we need some new channel >>>>>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers >>>>>>>> and events) for managing these digital data sources/sinks that are not an >>>>>>>> IIO buffer. >>>>>>>> >>>>>>> >>>>>>> But what would be that channel? In the end of the day, we typically have voltage or >>>>>>> current DACs and a DDS primary function is indeed to generate alternating waveforms >>>>>>> that you then typically feed into a DAC (and in some cases from the DAC into a >>>>>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure >>>>>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: >>>>>>> >>>>>>> . frequency >>>>>>> . phase >>>>>>> . amplitude (raw + scale + offset) >>>>>>> >>>>>>> But you're right that maybe it's time to think in a better way to fit them together. >>>>>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan >>>>>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). >>>>>>> >>>>>>> And spoiler alert, as you might have guessed already, the parallel port stuff is to be >>>>>>> used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo >>>>>>> can confirm it. >>>>>>> >>>>>>>> I think we've seen enough of these already to know that things like a >>>>>>>> "tone generator" and a "ramp generator" are going to be common and could >>>>>>>> share some standard attributes. >>>>>>>> >>>>>>> >>>>>>> I tend to agree. For example, there already some DACs (with dithering) that make use of a similar >>>>>>> interface (but with a custom prefix). Though the end goal is different, the interface is not that >>>>>>> far off: >>>>>>> >>>>>>> >>>>>>> https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 >>>>>>> >>>>>>> Anyways, I knew this one would be an interesting one for upstream :) >>>>>> >>>>>> For history buffs, we had a bunch of DDS chips in staging at one point and never >>>>>> manage to figure out the questions being raised here :( They are complex >>>>>> beasts. Clarity of ABI proposal and documentation is going to be key to driving >>>>>> this series forwards. In a sense the code is the easy part. >>>>> >>>>> Does that mean that once good documentation is provided, the presented design can >>>>> be accepted? Even though data generators/sources might not be interpreted as >>>>> altvoltage channels? >>>> >>>> I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion >>>> on how to handle this channel 'mixing' case. >>>> >>>> If we did go this way, we'd need to figure out a way to describe the mixing part. >>>> So either we describe it as one channel (which is going to be really complex) >>>> or we describe it as multiple channels but add extra ABI to make it clear they >>>> are mixed into a single 'physical' channel. >>>> >>>> Jonathan >>>> >>>>> >>>> >>> >>> Some ideas have crossed my mind, like adding new option to the in_/out_ >>> prefix for "internal" channels. But I it would take a long time to teach >>> existing generic userspace libraries/tools about this. >>> >>> What has popped into my head just now is that perhaps we could do like >>> Rodrigo is proposing here reusing existing channels and standard attributes >>> as much as possible and add a new "subcomponent_of" attribute to provide >>> the link, similar to "current_trigger" for triggers. >>> >>> This way, it would still work with existing userspace tools (even if it >>> looks a bit confusing). And userspace tools could eventually be taught >>> to present the channels as a tree-like structure with the main channel >>> and subcomponents nested under it. >>> >>> We would want to spell out up front what all of the anticipated ways of >>> using it are. For example, I suspect eventually someone will want this >>> attribute to be writeable to assign a specific limited resource to a >>> specific channel. An I expect that we would eventually see something were >>> a single subcomponent is shared between multiple physical channels. In >>> this case, we would want the value of the "subcomponent_of" attribute to >>> be able to be a list. >> >> Something along those lines might work. I'd not thought about the case >> of one 'internal' going to multiple 'external'. Otherwise I was wondering >> if something informal related to labels would work. We've done that where >> we've been associating things like voltage and power measurement from a single >> pin. It's rather adhoc though. Possibly we could roll it into a newer >> more general scheme. Hmm... in this case, it sounds more flat where there isn't a clear channel that would be the "root" of a tree relation. >> >> If the association is done as meta data attributes alongside existing >> channels then as you say existing tools will kind of work, just need some >> human understanding of what is actually being controlled until they catch >> up with the newer schemes. >> >> Lots of ways we could actually represent the graphs. Going to take some >> figuring out! > > I like the idea of subchannels to create logical tree-structures. It opens > up for other possibilities. > > I wonder if the varying channel index would still confuse a user, even > with this metadata attribute, like: > - out_altvoltage0 > - out_altvoltage1 > - out_altvoltage1_subcomponent_of = out_altvoltage0 > > would there be a different way to name the full_postfix in > __iio_device_attr_init() that would allow to keep channel index the same > (e.g. altvoltage0 for multiple internal sub-channel) and still be > compatible with userspace tools? I don't know, something like: > - out_altvoltage0 > - out_altvoltage0_0 > - out_altvoltage0_1 > - out_altvoltage0_2 > > userspace tools would understand out_altvoltage0_0_frequency as: > - direction: out > - type: altvoltage > - channel idx: 0 > - attr name: 0_frequency > > and that would be a problem? > I have a feeling that could be problematic for existing attribute parsers. How about using higher numbered channel indexes instead? out_altvoltage100_* = physical channel out_altvoltage101_* = subcomponent out_altvoltage102_* = subcomponent ...
On Sat, 7 Mar 2026 14:01:14 -0600 David Lechner <dlechner@baylibre.com> wrote: > On 3/7/26 12:54 PM, Rodrigo Alencar wrote: > > On 26/03/07 04:58PM, Jonathan Cameron wrote: > >> On Sat, 7 Mar 2026 10:50:14 -0600 > >> David Lechner <dlechner@baylibre.com> wrote: > >> > >>> On 3/7/26 8:09 AM, Jonathan Cameron wrote: > >>>> On Mon, 2 Mar 2026 10:22:47 +0000 > >>>> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > >>>> > >>>>> On 26/03/01 01:38PM, Jonathan Cameron wrote: > >>>>>> On Mon, 23 Feb 2026 10:02:00 +0000 > >>>>>> Nuno Sá <noname.nuno@gmail.com> wrote: > >>>>>> > >>>>>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > >>>>>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > >>>>>>>>> On 26/02/21 02:16PM, David Lechner wrote: > >>>>>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > >>>>>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. > >>>>>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> ... > >>>>>>>> > >>>>>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver > >>>>>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > >>>>>>>>>> > >>>>>>>>>> Generally IIO channels represent the physical input/output, not the > >>>>>>>>>> internal channels. > >>>>>>>>> > >>>>>>>>> That is part of the reason for this RFC. Dividing those top-level modes > >>>>>>>>> into channels allows for better organization, as they can operate together, > >>>>>>>>> i.e., phase or scale can be provided by single-tone profile, while > >>>>>>>>> frequency is controlled by the digital ramp generator (see Mode Priority > >>>>>>>>> section in the datasheet). Also, it allows to explore the most of standard > >>>>>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. > >>>>>>>>> Putting everything into a single channel would make things a lot messy > >>>>>>>>> to interface with. > >>>>>>>>> > >>>>>>>>>> Ideally we would just have the one channel here with a mode selection > >>>>>>>>>> attribute. Documentation can tell us which modes use which attributes. > >>>>>>>>>> > >>>>>>>>>>> This per-channel separation allows userspace to configure each mode > >>>>>>>>>>> independently through its own set of sysfs attributes, and to > >>>>>>>>>>> enable/disable modes individually via IIO_CHAN_INFO_ENABLE, relying on > >>>>>>>>>>> the hardware's own mode selection architecture. > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> Looking at Table 5 in the datasheet really helped me understand this better. > >>>>>>>> I think this series could benefit from a documentation patch that explains > >>>>>>>> more about how the driver works with some diagrams. > >>>>>>>> > >>>>>>>> So really what we have here are a bunch of digital data generators rather > >>>>>>>> than a bunch of altvotlage output channels. And the same data channels can be > >>>>>>>> mixed and match as the source for up to 3 different components of the output > >>>>>>>> (frequency, phase, amplitude) depending on the priority rules defined in > >>>>>>>> Table 5. > >>>>>>> > >>>>>>> More bellow... But note that all of the (or most of it) generators are going to > >>>>>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the > >>>>>>> internals as voltage. Not sure. > >>>>>>> > >>>>>>>> > >>>>>>>> Digital data sources are really more like a buffer in IIO terms than a > >>>>>>>> channel. And before we added the IIO backend stuff, there wasn't really > >>>>>>>> any other digital data source/sink that I am aware of other than buffers > >>>>>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored > >>>>>>>> yet, so maybe I missed some). > >>>>>>>> > >>>>>>>> In a recent discussion, the idea of possibly needing a way to provide > >>>>>>>> some userspace interface to be able to tweak knobs of an IIO backend > >>>>>>>> was also brought up. > >>>>>>>> > >>>>>>>> Putting those ideas together, I'm wondering if we need some new channel > >>>>>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers > >>>>>>>> and events) for managing these digital data sources/sinks that are not an > >>>>>>>> IIO buffer. > >>>>>>>> > >>>>>>> > >>>>>>> But what would be that channel? In the end of the day, we typically have voltage or > >>>>>>> current DACs and a DDS primary function is indeed to generate alternating waveforms > >>>>>>> that you then typically feed into a DAC (and in some cases from the DAC into a > >>>>>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > >>>>>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: > >>>>>>> > >>>>>>> . frequency > >>>>>>> . phase > >>>>>>> . amplitude (raw + scale + offset) > >>>>>>> > >>>>>>> But you're right that maybe it's time to think in a better way to fit them together. > >>>>>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > >>>>>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). > >>>>>>> > >>>>>>> And spoiler alert, as you might have guessed already, the parallel port stuff is to be > >>>>>>> used with DMA buffers (and IIO backends). At least, that was the plan IIRC. But Rodrigo > >>>>>>> can confirm it. > >>>>>>> > >>>>>>>> I think we've seen enough of these already to know that things like a > >>>>>>>> "tone generator" and a "ramp generator" are going to be common and could > >>>>>>>> share some standard attributes. > >>>>>>>> > >>>>>>> > >>>>>>> I tend to agree. For example, there already some DACs (with dithering) that make use of a similar > >>>>>>> interface (but with a custom prefix). Though the end goal is different, the interface is not that > >>>>>>> far off: > >>>>>>> > >>>>>>> > >>>>>>> https://elixir.bootlin.com/linux/v6.19.3/source/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 > >>>>>>> > >>>>>>> Anyways, I knew this one would be an interesting one for upstream :) > >>>>>> > >>>>>> For history buffs, we had a bunch of DDS chips in staging at one point and never > >>>>>> manage to figure out the questions being raised here :( They are complex > >>>>>> beasts. Clarity of ABI proposal and documentation is going to be key to driving > >>>>>> this series forwards. In a sense the code is the easy part. > >>>>> > >>>>> Does that mean that once good documentation is provided, the presented design can > >>>>> be accepted? Even though data generators/sources might not be interpreted as > >>>>> altvoltage channels? > >>>> > >>>> I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion > >>>> on how to handle this channel 'mixing' case. > >>>> > >>>> If we did go this way, we'd need to figure out a way to describe the mixing part. > >>>> So either we describe it as one channel (which is going to be really complex) > >>>> or we describe it as multiple channels but add extra ABI to make it clear they > >>>> are mixed into a single 'physical' channel. > >>>> > >>>> Jonathan > >>>> > >>>>> > >>>> > >>> > >>> Some ideas have crossed my mind, like adding new option to the in_/out_ > >>> prefix for "internal" channels. But I it would take a long time to teach > >>> existing generic userspace libraries/tools about this. > >>> > >>> What has popped into my head just now is that perhaps we could do like > >>> Rodrigo is proposing here reusing existing channels and standard attributes > >>> as much as possible and add a new "subcomponent_of" attribute to provide > >>> the link, similar to "current_trigger" for triggers. > >>> > >>> This way, it would still work with existing userspace tools (even if it > >>> looks a bit confusing). And userspace tools could eventually be taught > >>> to present the channels as a tree-like structure with the main channel > >>> and subcomponents nested under it. > >>> > >>> We would want to spell out up front what all of the anticipated ways of > >>> using it are. For example, I suspect eventually someone will want this > >>> attribute to be writeable to assign a specific limited resource to a > >>> specific channel. An I expect that we would eventually see something were > >>> a single subcomponent is shared between multiple physical channels. In > >>> this case, we would want the value of the "subcomponent_of" attribute to > >>> be able to be a list. > >> > >> Something along those lines might work. I'd not thought about the case > >> of one 'internal' going to multiple 'external'. Otherwise I was wondering > >> if something informal related to labels would work. We've done that where > >> we've been associating things like voltage and power measurement from a single > >> pin. It's rather adhoc though. Possibly we could roll it into a newer > >> more general scheme. > > Hmm... in this case, it sounds more flat where there isn't a clear channel > that would be the "root" of a tree relation. > > >> > >> If the association is done as meta data attributes alongside existing > >> channels then as you say existing tools will kind of work, just need some > >> human understanding of what is actually being controlled until they catch > >> up with the newer schemes. > >> > >> Lots of ways we could actually represent the graphs. Going to take some > >> figuring out! > > > > I like the idea of subchannels to create logical tree-structures. It opens > > up for other possibilities. > > > > I wonder if the varying channel index would still confuse a user, even > > with this metadata attribute, like: > > - out_altvoltage0 > > - out_altvoltage1 > > - out_altvoltage1_subcomponent_of = out_altvoltage0 > > > > would there be a different way to name the full_postfix in > > __iio_device_attr_init() that would allow to keep channel index the same > > (e.g. altvoltage0 for multiple internal sub-channel) and still be > > compatible with userspace tools? I don't know, something like: > > - out_altvoltage0 > > - out_altvoltage0_0 > > - out_altvoltage0_1 > > - out_altvoltage0_2 > > > > userspace tools would understand out_altvoltage0_0_frequency as: > > - direction: out > > - type: altvoltage > > - channel idx: 0 > > - attr name: 0_frequency > > > > and that would be a problem? > > > > I have a feeling that could be problematic for existing attribute > parsers. Agreed. This smells like extend_name and that caused all sorts of annoying problems for the userspace folk. > > How about using higher numbered channel indexes instead? > > out_altvoltage100_* = physical channel > > out_altvoltage101_* = subcomponent > out_altvoltage102_* = subcomponent > ... Have to be careful we don't run out of space for events. #define IIO_EVENT_CODE_EXTRACT_CHAN(mask) ((__s16)(mask & 0xFFFF)) So we do have 16 bits hence this might work. I'm not sure we want to make rules around this though. Jonathan >
On 26/03/08 06:12PM, Jonathan Cameron wrote: > On Sat, 7 Mar 2026 14:01:14 -0600 > David Lechner <dlechner@baylibre.com> wrote: > > > On 3/7/26 12:54 PM, Rodrigo Alencar wrote: > > > On 26/03/07 04:58PM, Jonathan Cameron wrote: > > >> On Sat, 7 Mar 2026 10:50:14 -0600 > > >> David Lechner <dlechner@baylibre.com> wrote: > > >> > > >>> On 3/7/26 8:09 AM, Jonathan Cameron wrote: > > >>>> On Mon, 2 Mar 2026 10:22:47 +0000 > > >>>> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > > >>>> > > >>>>> On 26/03/01 01:38PM, Jonathan Cameron wrote: > > >>>>>> On Mon, 23 Feb 2026 10:02:00 +0000 > > >>>>>> Nuno Sá <noname.nuno@gmail.com> wrote: > > >>>>>> > > >>>>>>> On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > >>>>>>>> On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > >>>>>>>>> On 26/02/21 02:16PM, David Lechner wrote: > > >>>>>>>>>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > >>>>>>>>>>> This patch series adds support for the Analog Devices AD9910 DDS. > > >>>>>>>>>>> This is an RFC so that we can agree/discuss on the design that follows: ... > > >>>>>>>>>>> represents a distinct signal path into the DDS accumulator, so the driver > > >>>>>>>>>>> models them as separate IIO output channels (all IIO_ALTVOLTAGE type). > > >>>>>>>>>> > > >>>>>>>>>> Generally IIO channels represent the physical input/output, not the > > >>>>>>>>>> internal channels. > > >>>>>>>>> > > >>>>>>>>> That is part of the reason for this RFC. Dividing those top-level modes > > >>>>>>>>> into channels allows for better organization, as they can operate together, > > >>>>>>>>> i.e., phase or scale can be provided by single-tone profile, while > > >>>>>>>>> frequency is controlled by the digital ramp generator (see Mode Priority > > >>>>>>>>> section in the datasheet). Also, it allows to explore the most of standard > > >>>>>>>>> ABIs like, scale, frequency, phase, sampling_frequency and enable. > > >>>>>>>>> Putting everything into a single channel would make things a lot messy > > >>>>>>>>> to interface with. ... > > >>>>>>>> Looking at Table 5 in the datasheet really helped me understand this better. > > >>>>>>>> I think this series could benefit from a documentation patch that explains > > >>>>>>>> more about how the driver works with some diagrams. > > >>>>>>>> > > >>>>>>>> So really what we have here are a bunch of digital data generators rather > > >>>>>>>> than a bunch of altvotlage output channels. And the same data channels can be > > >>>>>>>> mixed and match as the source for up to 3 different components of the output > > >>>>>>>> (frequency, phase, amplitude) depending on the priority rules defined in > > >>>>>>>> Table 5. > > >>>>>>> > > >>>>>>> More bellow... But note that all of the (or most of it) generators are going to > > >>>>>>> be feed into a DAC. Your output is altvoltage but maybe we can treat the > > >>>>>>> internals as voltage. Not sure. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> Digital data sources are really more like a buffer in IIO terms than a > > >>>>>>>> channel. And before we added the IIO backend stuff, there wasn't really > > >>>>>>>> any other digital data source/sink that I am aware of other than buffers > > >>>>>>>> (but there are certainly a lot of odd corners of IIO that I haven't explored > > >>>>>>>> yet, so maybe I missed some). > > >>>>>>>> > > >>>>>>>> In a recent discussion, the idea of possibly needing a way to provide > > >>>>>>>> some userspace interface to be able to tweak knobs of an IIO backend > > >>>>>>>> was also brought up. > > >>>>>>>> > > >>>>>>>> Putting those ideas together, I'm wondering if we need some new channel > > >>>>>>>> type or even a whole new interface (e.g. a new sysfs directory like buffers > > >>>>>>>> and events) for managing these digital data sources/sinks that are not an > > >>>>>>>> IIO buffer. > > >>>>>>>> > > >>>>>>> > > >>>>>>> But what would be that channel? In the end of the day, we typically have voltage or > > >>>>>>> current DACs and a DDS primary function is indeed to generate alternating waveforms > > >>>>>>> that you then typically feed into a DAC (and in some cases from the DAC into a > > >>>>>>> power amplifier). So the DDS is just part of the data/signal path. Anyways, not sure > > >>>>>>> on the new type and I think we already have the "blocks" in IIO for dealing with this: > > >>>>>>> > > >>>>>>> . frequency > > >>>>>>> . phase > > >>>>>>> . amplitude (raw + scale + offset) > > >>>>>>> > > >>>>>>> But you're right that maybe it's time to think in a better way to fit them together. > > >>>>>>> Maybe a new type (as buffers or events) can make sense where the above are treated as, example, scan > > >>>>>>> elements. Maybe it's overcomplicating, not sure. It surely needs discussion and thinking :). ... > > >>>>>> For history buffs, we had a bunch of DDS chips in staging at one point and never > > >>>>>> manage to figure out the questions being raised here :( They are complex > > >>>>>> beasts. Clarity of ABI proposal and documentation is going to be key to driving > > >>>>>> this series forwards. In a sense the code is the easy part. > > >>>>> > > >>>>> Does that mean that once good documentation is provided, the presented design can > > >>>>> be accepted? Even though data generators/sources might not be interpreted as > > >>>>> altvoltage channels? > > >>>> > > >>>> I'm not sure yet :( It's a pretty complex design and we haven't really come to a conclusion > > >>>> on how to handle this channel 'mixing' case. > > >>>> > > >>>> If we did go this way, we'd need to figure out a way to describe the mixing part. > > >>>> So either we describe it as one channel (which is going to be really complex) > > >>>> or we describe it as multiple channels but add extra ABI to make it clear they > > >>>> are mixed into a single 'physical' channel. > > >>>> ... > > >>> Some ideas have crossed my mind, like adding new option to the in_/out_ > > >>> prefix for "internal" channels. But I it would take a long time to teach > > >>> existing generic userspace libraries/tools about this. > > >>> > > >>> What has popped into my head just now is that perhaps we could do like > > >>> Rodrigo is proposing here reusing existing channels and standard attributes > > >>> as much as possible and add a new "subcomponent_of" attribute to provide > > >>> the link, similar to "current_trigger" for triggers. > > >>> > > >>> This way, it would still work with existing userspace tools (even if it > > >>> looks a bit confusing). And userspace tools could eventually be taught > > >>> to present the channels as a tree-like structure with the main channel > > >>> and subcomponents nested under it. > > >>> > > >>> We would want to spell out up front what all of the anticipated ways of > > >>> using it are. For example, I suspect eventually someone will want this > > >>> attribute to be writeable to assign a specific limited resource to a > > >>> specific channel. An I expect that we would eventually see something were > > >>> a single subcomponent is shared between multiple physical channels. In > > >>> this case, we would want the value of the "subcomponent_of" attribute to > > >>> be able to be a list. > > >> > > >> Something along those lines might work. I'd not thought about the case > > >> of one 'internal' going to multiple 'external'. Otherwise I was wondering > > >> if something informal related to labels would work. We've done that where > > >> we've been associating things like voltage and power measurement from a single > > >> pin. It's rather adhoc though. Possibly we could roll it into a newer > > >> more general scheme. > > > > Hmm... in this case, it sounds more flat where there isn't a clear channel > > that would be the "root" of a tree relation. > > > > >> > > >> If the association is done as meta data attributes alongside existing > > >> channels then as you say existing tools will kind of work, just need some > > >> human understanding of what is actually being controlled until they catch > > >> up with the newer schemes. > > >> > > >> Lots of ways we could actually represent the graphs. Going to take some > > >> figuring out! > > > > > > I like the idea of subchannels to create logical tree-structures. It opens > > > up for other possibilities. > > > > > > I wonder if the varying channel index would still confuse a user, even > > > with this metadata attribute, like: > > > - out_altvoltage0 > > > - out_altvoltage1 > > > - out_altvoltage1_subcomponent_of = out_altvoltage0 > > > > > > would there be a different way to name the full_postfix in > > > __iio_device_attr_init() that would allow to keep channel index the same > > > (e.g. altvoltage0 for multiple internal sub-channel) and still be > > > compatible with userspace tools? I don't know, something like: > > > - out_altvoltage0 > > > - out_altvoltage0_0 > > > - out_altvoltage0_1 > > > - out_altvoltage0_2 > > > > > > userspace tools would understand out_altvoltage0_0_frequency as: > > > - direction: out > > > - type: altvoltage > > > - channel idx: 0 > > > - attr name: 0_frequency > > > > > > and that would be a problem? > > > > > > > I have a feeling that could be problematic for existing attribute > > parsers. > > Agreed. This smells like extend_name and that caused all sorts > of annoying problems for the userspace folk. > > > > > How about using higher numbered channel indexes instead? > > > > out_altvoltage100_* = physical channel > > > > out_altvoltage101_* = subcomponent > > out_altvoltage102_* = subcomponent > > ... > Have to be careful we don't run out of space for events. > #define IIO_EVENT_CODE_EXTRACT_CHAN(mask) ((__s16)(mask & 0xFFFF)) > So we do have 16 bits hence this might work. > > I'm not sure we want to make rules around this though. Ok, I think we are reaching an agreement. With this, I think there is room for a small redesign, i.e., having a root channel to represent the physical DAC and child channels as follows (* on custom ABI): - out_altvoltage100: root/physical channel - profile*: for profile selection - sampling_frequency: sysclk frequency value - out_altvoltage110: single tone channel - frequency: single tone profile FTW - phase: single tone profile POW - scale: single tone profile ASF - out_altvoltage120: parallel port channel - en - frequency_scale* or frequency_gain*: for FM gain - frequency or frequency_offset* - phase or phase_offset* - scale or scale_offset* - out_altvoltage130: drg channel - en - destination* - operating_mode* - out_altvoltage131: drg upper limit channel - frequency - frequency_step* - phase - phase_step* - scale - scale_step* - sampling_frequency - out_altvoltage132: drg lower limit channel - frequency - frequency_step* - phase - phase_step* - scale - scale_step* - sampling_frequency - out_altvoltage140: ram channel - en - frequency: global FTW - phase: global POW - sampling_frequency - destination* - operating_mode* - address_start* - address_end* - out_altvoltage150: osk channel - en - scale: global ASF - scale_step* - sampling_frequency - pinctrl_en* so I ended up with 8 channels (rather than the initial 5). Breaking up the DRG channel, following the tree structure allows to explore more of the standard ABI. I suppose that even with this, documentation is no less important. How does it look? -- Kind regards, Rodrigo Alencar
On Mon, 2026-03-09 at 09:52 +0000, Rodrigo Alencar wrote: > On 26/03/08 06:12PM, Jonathan Cameron wrote: > > On Sat, 7 Mar 2026 14:01:14 -0600 > > David Lechner <dlechner@baylibre.com> wrote: > > > > > On 3/7/26 12:54 PM, Rodrigo Alencar wrote: > > > > On 26/03/07 04:58PM, Jonathan Cameron wrote: > > > > > On Sat, 7 Mar 2026 10:50:14 -0600 > > > > > David Lechner <dlechner@baylibre.com> wrote: > > > > > > > > > > > On 3/7/26 8:09 AM, Jonathan Cameron wrote: > > > > > > > On Mon, 2 Mar 2026 10:22:47 +0000 > > > > > > > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote: > > > > > > > > > > > > > > > On 26/03/01 01:38PM, Jonathan Cameron wrote: > > > > > > > > > On Mon, 23 Feb 2026 10:02:00 +0000 > > > > > > > > > Nuno Sá <noname.nuno@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > On Sun, 2026-02-22 at 14:32 -0600, David Lechner wrote: > > > > > > > > > > > On 2/22/26 4:01 AM, Rodrigo Alencar wrote: > > > > > > > > > > > > On 26/02/21 02:16PM, David Lechner wrote: > > > > > > > > > > > > > On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote: > > > > > > > > > > > > > > This patch series adds support for the Analog Devices AD9910 DDS. > > > > > > > > > > > > > > This is an RFC so that we can agree/discuss on the design that follows: > > ... > > > > > > > > > > > > > > > represents a distinct signal path into the DDS accumulator, so the > > > > > > > > > > > > > > driver > > > > > > > > > > > > > > models them as separate IIO output channels (all IIO_ALTVOLTAGE > > > > > > > > > > > > > > type). > > > > > > > > > > > > > > > > > > > > > > > > > > Generally IIO channels represent the physical input/output, not the > > > > > > > > > > > > > internal channels. > > > > > > > > > > > > > > > > > > > > > > > > That is part of the reason for this RFC. Dividing those top-level modes > > > > > > > > > > > > into channels allows for better organization, as they can operate together, > > > > > > > > > > > > i.e., phase or scale can be provided by single-tone profile, while > > > > > > > > > > > > frequency is controlled by the digital ramp generator (see Mode Priority > > > > > > > > > > > > section in the datasheet). Also, it allows to explore the most of standard > > > > > > > > > > > > ABIs like, scale, frequency, phase, sampling_frequency and enable. > > > > > > > > > > > > Putting everything into a single channel would make things a lot messy > > > > > > > > > > > > to interface with. > > ... > > > > > > > > > > > > Looking at Table 5 in the datasheet really helped me understand this better. > > > > > > > > > > > I think this series could benefit from a documentation patch that explains > > > > > > > > > > > more about how the driver works with some diagrams. > > > > > > > > > > > > > > > > > > > > > > So really what we have here are a bunch of digital data generators rather > > > > > > > > > > > than a bunch of altvotlage output channels. And the same data channels can be > > > > > > > > > > > mixed and match as the source for up to 3 different components of the output > > > > > > > > > > > (frequency, phase, amplitude) depending on the priority rules defined in > > > > > > > > > > > Table 5. > > > > > > > > > > > > > > > > > > > > More bellow... But note that all of the (or most of it) generators are going to > > > > > > > > > > be feed into a DAC. Your output is altvoltage but maybe we can treat the > > > > > > > > > > internals as voltage. Not sure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Digital data sources are really more like a buffer in IIO terms than a > > > > > > > > > > > channel. And before we added the IIO backend stuff, there wasn't really > > > > > > > > > > > any other digital data source/sink that I am aware of other than buffers > > > > > > > > > > > (but there are certainly a lot of odd corners of IIO that I haven't explored > > > > > > > > > > > yet, so maybe I missed some). > > > > > > > > > > > > > > > > > > > > > > In a recent discussion, the idea of possibly needing a way to provide > > > > > > > > > > > some userspace interface to be able to tweak knobs of an IIO backend > > > > > > > > > > > was also brought up. > > > > > > > > > > > > > > > > > > > > > > Putting those ideas together, I'm wondering if we need some new channel > > > > > > > > > > > type or even a whole new interface (e.g. a new sysfs directory like buffers > > > > > > > > > > > and events) for managing these digital data sources/sinks that are not an > > > > > > > > > > > IIO buffer. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But what would be that channel? In the end of the day, we typically have voltage > > > > > > > > > > or > > > > > > > > > > current DACs and a DDS primary function is indeed to generate alternating > > > > > > > > > > waveforms > > > > > > > > > > that you then typically feed into a DAC (and in some cases from the DAC into a > > > > > > > > > > power amplifier). So the DDS is just part of the data/signal path. Anyways, not > > > > > > > > > > sure > > > > > > > > > > on the new type and I think we already have the "blocks" in IIO for dealing with > > > > > > > > > > this: > > > > > > > > > > > > > > > > > > > > . frequency > > > > > > > > > > . phase > > > > > > > > > > . amplitude (raw + scale + offset) > > > > > > > > > > > > > > > > > > > > But you're right that maybe it's time to think in a better way to fit them > > > > > > > > > > together. > > > > > > > > > > Maybe a new type (as buffers or events) can make sense where the above are > > > > > > > > > > treated as, example, scan > > > > > > > > > > elements. Maybe it's overcomplicating, not sure. It surely needs discussion and > > > > > > > > > > thinking :). > > ... > > > > > > > > > > For history buffs, we had a bunch of DDS chips in staging at one point and never > > > > > > > > > manage to figure out the questions being raised here :( They are complex > > > > > > > > > beasts. Clarity of ABI proposal and documentation is going to be key to driving > > > > > > > > > this series forwards. In a sense the code is the easy part. > > > > > > > > > > > > > > > > Does that mean that once good documentation is provided, the presented design can > > > > > > > > be accepted? Even though data generators/sources might not be interpreted as > > > > > > > > altvoltage channels? > > > > > > > > > > > > > > I'm not sure yet :( It's a pretty complex design and we haven't really come to a > > > > > > > conclusion > > > > > > > on how to handle this channel 'mixing' case. > > > > > > > > > > > > > > If we did go this way, we'd need to figure out a way to describe the mixing part. > > > > > > > So either we describe it as one channel (which is going to be really complex) > > > > > > > or we describe it as multiple channels but add extra ABI to make it clear they > > > > > > > are mixed into a single 'physical' channel. > > > > > > > > > ... > > > > > > > Some ideas have crossed my mind, like adding new option to the in_/out_ > > > > > > prefix for "internal" channels. But I it would take a long time to teach > > > > > > existing generic userspace libraries/tools about this. > > > > > > > > > > > > What has popped into my head just now is that perhaps we could do like > > > > > > Rodrigo is proposing here reusing existing channels and standard attributes > > > > > > as much as possible and add a new "subcomponent_of" attribute to provide > > > > > > the link, similar to "current_trigger" for triggers. > > > > > > > > > > > > This way, it would still work with existing userspace tools (even if it > > > > > > looks a bit confusing). And userspace tools could eventually be taught > > > > > > to present the channels as a tree-like structure with the main channel > > > > > > and subcomponents nested under it. > > > > > > > > > > > > We would want to spell out up front what all of the anticipated ways of > > > > > > using it are. For example, I suspect eventually someone will want this > > > > > > attribute to be writeable to assign a specific limited resource to a > > > > > > specific channel. An I expect that we would eventually see something were > > > > > > a single subcomponent is shared between multiple physical channels. In > > > > > > this case, we would want the value of the "subcomponent_of" attribute to > > > > > > be able to be a list. > > > > > > > > > > Something along those lines might work. I'd not thought about the case > > > > > of one 'internal' going to multiple 'external'. Otherwise I was wondering > > > > > if something informal related to labels would work. We've done that where > > > > > we've been associating things like voltage and power measurement from a single > > > > > pin. It's rather adhoc though. Possibly we could roll it into a newer > > > > > more general scheme. > > > > > > Hmm... in this case, it sounds more flat where there isn't a clear channel > > > that would be the "root" of a tree relation. > > > > > > > > > > > > > If the association is done as meta data attributes alongside existing > > > > > channels then as you say existing tools will kind of work, just need some > > > > > human understanding of what is actually being controlled until they catch > > > > > up with the newer schemes. > > > > > > > > > > Lots of ways we could actually represent the graphs. Going to take some > > > > > figuring out! > > > > > > > > I like the idea of subchannels to create logical tree-structures. It opens > > > > up for other possibilities. > > > > > > > > I wonder if the varying channel index would still confuse a user, even > > > > with this metadata attribute, like: > > > > - out_altvoltage0 > > > > - out_altvoltage1 > > > > - out_altvoltage1_subcomponent_of = out_altvoltage0 > > > > > > > > would there be a different way to name the full_postfix in > > > > __iio_device_attr_init() that would allow to keep channel index the same > > > > (e.g. altvoltage0 for multiple internal sub-channel) and still be > > > > compatible with userspace tools? I don't know, something like: > > > > - out_altvoltage0 > > > > - out_altvoltage0_0 > > > > - out_altvoltage0_1 > > > > - out_altvoltage0_2 > > > > > > > > userspace tools would understand out_altvoltage0_0_frequency as: > > > > - direction: out > > > > - type: altvoltage > > > > - channel idx: 0 > > > > - attr name: 0_frequency > > > > > > > > and that would be a problem? > > > > > > > > > > I have a feeling that could be problematic for existing attribute > > > parsers. > > > > Agreed. This smells like extend_name and that caused all sorts > > of annoying problems for the userspace folk. > > > > > > > > How about using higher numbered channel indexes instead? > > > > > > out_altvoltage100_* = physical channel > > > > > > out_altvoltage101_* = subcomponent > > > out_altvoltage102_* = subcomponent > > > ... > > Have to be careful we don't run out of space for events. > > #define IIO_EVENT_CODE_EXTRACT_CHAN(mask) ((__s16)(mask & 0xFFFF)) > > So we do have 16 bits hence this might work. > > > > I'm not sure we want to make rules around this though. > > Ok, I think we are reaching an agreement. With this, I think there > is room for a small redesign, i.e., having a root channel to represent > the physical DAC and child channels as follows (* on custom ABI): > - out_altvoltage100: root/physical channel > - profile*: for profile selection > - sampling_frequency: sysclk frequency value > - out_altvoltage110: single tone channel > - frequency: single tone profile FTW > - phase: single tone profile POW > - scale: single tone profile ASF > - out_altvoltage120: parallel port channel > - en > - frequency_scale* or frequency_gain*: for FM gain > - frequency or frequency_offset* > - phase or phase_offset* > - scale or scale_offset* > - out_altvoltage130: drg channel > - en > - destination* > - operating_mode* > - out_altvoltage131: drg upper limit channel > - frequency > - frequency_step* > - phase > - phase_step* > - scale > - scale_step* > - sampling_frequency > - out_altvoltage132: drg lower limit channel > - frequency > - frequency_step* > - phase > - phase_step* > - scale > - scale_step* > - sampling_frequency > - out_altvoltage140: ram channel > - en > - frequency: global FTW > - phase: global POW > - sampling_frequency > - destination* > - operating_mode* > - address_start* > - address_end* > - out_altvoltage150: osk channel > - en > - scale: global ASF > - scale_step* > - sampling_frequency > - pinctrl_en* > > so I ended up with 8 channels (rather than the initial 5). Breaking up the > DRG channel, following the tree structure allows to explore more of the > standard ABI. I suppose that even with this, documentation is no less > important. How does it look? FWIW, I kind of like this "child" channel concept and think it might be useful for other things to. One thing that comes to mind is how do we want to handle this in terms of scan_elements? Do we have it completely independent or do we want to play some games with it? Like allowing arbitrary sizes (not power of 2) in child channels as long as the sum matches what was defined in the parent/physical channel. One usecase for the above would be the ad4030 ADC where we went with two channels (for the common mode voltage) for one physical one and we define two scan elements where the total storage does not directly map the actual physical size. And while we can get away with it for SW buffers, for HW buffers it's not "so simple". Can be a bit tricky to implement but the above concept might open the door for it. - Nuno Sá
© 2016 - 2026 Red Hat, Inc.