Re: [PATCH] staging: Documentation: dds: replace frequencyY with frequency

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 12 May 2026 22:14:34 +0530
Abinash Singh <abinashsinghlalotra@gmail.com> wrote:

> Hi Jonathan
> 
> On Tue, May 12, 2026 at 7:38 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Mon, 11 May 2026 22:42:55 +0530
> > Abinash Singh <abinashsinghlalotra@gmail.com> wrote:
> >  
> > > From: Abinash Singh <abinashlalotra@gmail.com>
> > >
> > > The documented frequencyY attribute naming is implementation
> > > specific and differs from common IIO sysfs attribute
> > > conventions.
> > >
> > > Replace the non-standard frequencyY attribute documentation with
> > > out_altvoltageX_frequency and document tuning word selection
> > > through out_altvoltageX_frequencysymbol
> > >
> > > This makes the documented ABI naming consistent with standard
> > > IIO sysfs attribute conventions and clarifies how tuning word
> > > registers are selected and programmed.
> > >  
> >
> > Hmm. So some history on why it was done like this (long time back
> > but I think I recall the basic argument).
> >
> > Consider the programming you need to set up FSK on a channel and
> > the fact that someone is recieving the result.
> >
> > When you set the symbol to program it that channel will begin
> > outputting the voltage. That means someone at the other end starts
> > decoding it.
> >
> > Hence we normally expect to set a frequency 'before' changing the
> > symbol.  Hence the per symbol files.
> >
> > There might be a valid way to set them up using your proposed
> > interface but I'm not currently understanding what it is.  
> 
> I think I misunderstood the purpose of
> out_altvoltageX_frequencysymbol.
> 
> I initially thought it was used to select which tuning word register
> to write into, whereas it actually selects the active output tuning
> word. That explains why my proposed interface was confusing.
> 
> The ordering requirement you described for FSK setup makes sense now.
> With separate frequency0/frequency1 files, userspace can configure both
> tuning words before switching the active symbol.
> 
> >
> > We went through the same dance with the more complex DDS that
> > Rodrigo is working on. Take a look at the multichannel approach
> > he is using.  It may apply here - I'm not sure.
> >  
> 
> With my approach we can have a new entry  /out_altvoltageX_frequencySelect
> which can act as a mux to write into FREQ0 and FREQ1 register
> via  /out_altvoltage_frequency.

We could but given that is custom ABI anyway, what is the advantage over
per symbol controls?  Generally 'mux' control sysfs attributes are harder
to use than separate files.  For starters you'd also need an
out_outvoltageX_symbolcount or something like that to know what values
can be used.  One file per symbol and that is explicit without yet
more descriptive ABI needing to be defined.


> 
> I will take a look at Rodrigo's multichannel DDS approach before
> proposing any ABI changes further. It would be helpful if you could
> share links to the relevant discussion or patches.

https://lore.kernel.org/all/20260508-ad9910-iio-driver-v4-0-d26bfd20ee3d@analog.com/

and the earlier versions of that series.

> 
> >  
> > >
> > > Signed-off-by: Abinash Singh <abinashlalotra@gmail.com>
> > > ---
> > >
> > > The out_altvoltageX_frequencysymbol and
> > > out_altvoltageX_frequency_scale attributes can be added
> > > through extended channel attributes (.ext_info in channel_spec struct of IIO)
> > >
> > > Feedback on this approach would be appreciated, and if
> > > there is some other way in your mind. I would like to
> > > work on that.
> > >
> > > I am also interested in working on the sysfs-bus-iio-dds
> > > documentation and the ad9834 driver. I recently bought an
> > > AD9833 IC for experimentation and testing.
> > >  
> > Excellent!
> >
> > Thanks,
> >
> > Jonathan
> >  
> > > Thanks  
> 
> 
> And do we need to really work on this documentation in order to work on ad9834.c
> What else can be done in ad9834.c apart from this naming.??

The challenge has always been the ABI for these.
We need to work out what it should be (which is kind of what Rodrigo is doing
in his RFCs) before we commit it in stone.  Whilst not ideal, we can evolve
an ABI for a driver in staging (for IIO anyway - be careful in other places)
but not once it is out of staging.

Jonathan

> 
> Thanks
> 
> Abinash Singh