Re: [PATCH RFC 0/8] AD9910 Direct Digital Synthesizer

[David Lechner]

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.