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

[Rodrigo Alencar]

On 26/03/01 01:38PM, Jonathan Cameron wrote:
> On Mon, 23 Feb 2026 10:02:00 +0000
> Nuno Sá <noname.nuno@xxxxxxxxx> 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