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

[Jonathan Cameron <jic23@kernel.org>]

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á
>