Re: [PATCH RFC 6/8] iio: frequency: ad9910: add RAM mode support

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 1 Mar 2026 13:31:53 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Fri, 20 Feb 2026 16:46:10 +0000
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> 
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > 
> > Add RAM channel with support for profile-based control. This includes:
> > - RAM data loading via binary sysfs attribute (ram_data);  
> 
> I'm not sure that's a long term viable path.  We either need
> to figure out how to do it as firmware file load, or via an output buffer.
> 
> Firmware load would probably be too static and I'm not sure quite
> how we map these to IIO output buffers.

We would have to carry it for ever which is very much not ideal.
The firmware approach has the same issue, but can be thought of
as defaults at boot time forever.  If no defaults then we use whatever
we come up with as the long term solution.

> 
> > - Per-profile RAM configuration (start/end address, step rate, operating
> >   mode, dwell control);
> > - RAM destination control (frequency, phase, amplitude, polar);
> > - RAM operating modes (direct switch, ramp up, bidirectional ramp,
> >   continuous bidirectional, continuous recirculate);
> > - Profile switching for RAM playback;
> > - Sampling frequency control via profile step rate;
> > - ram_en-aware read/write paths that redirect single tone
> >   frequency/phase/amplitude access through reg_profile cache when RAM is
> >   active;
> > 
> > When RAM is enabled, the DDS core parameters (frequency, phase, amplitude)
> > for the single tone channel are sourced from a shadow register cache
> > (reg_profile[]) since the profile registers are repurposed for RAM control.
> > 
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > ---  
> 
> 
>