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

[Rodrigo Alencar]

On 26/03/07 02:07PM, Jonathan Cameron wrote:
> On Sun, 1 Mar 2026 13:31:53 +0000
> Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> 
> > On Fri, 20 Feb 2026 16:46:10 +0000
> > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@xxxxxxxxxx> wrote:
> > 
> > > From: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> > > 
> > > 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.

I was thinking about the firmware approach:
- Normally a driver would request the firmware during probe and the
  filename would be pre-defined.
- Less statically, It could have an attribute that once written, it would
  request the RAM contents (e.g. under /lib/firmware/ad9910_ram.bin).
  It could be the enable attribute itself (but that would not be effective
  when the binary would not change), or a separate one (e.g. destination),
  or a new one (e.g. load_en)
- Alternatively  we can also have an attribute (like 'filename') that once written,
  loads a firmware file under /lib/firmware/<value-of-filename>.bin 

I am currently using libiio to write the sysfs binary attribute. Thus,
the downside of the firmware approach is that I would have to use something
else when changing a firmware file remotely (as libiio would not support this).
 
Also, the buffer approach has its problems, mostly because triggered buffers
are not really designed for multi-buffer support, even though it could work
along side the DMA engine one (that I am using with the parallel port).
Additionally, userspace tools are not yet ready for multi-buffer support.
Also, an IIO buffer might give a sense of data streaming capabilities,
not a one-shot load that I need here.

-- 
Kind regards,

Rodrigo Alencar