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

[Rodrigo Alencar]

On 26/03/03 05:16PM, Nuno Sá wrote:
> On Tue, 2026-03-03 at 15:32 +0000, Rodrigo Alencar wrote:
> > On 26/03/01 01:31PM, Jonathan Cameron 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.
> > 
> > Could you develop on this? it is not viable because iio would drop that
> > support? using sysfs_create_bin_file() directly would be better?
> > 
> > > Firmware load would probably be too static and I'm not sure quite
> > > how we map these to IIO output buffers.
> > 
> > will investigate this buffer route. At this point, we can have multiple
> > buffers, right? I have the DMA engine buffer working with the parallel port.
> > 
> > ... 
> 
> In theory yes but we do have some issues with the implementation. I have some
> fixes but for code that, unfortunately, cannot land upstream anytime soon and with
> no users, these fixes can be an hard sell. So if we go the multi buffer support it
> could be a great opportunity for these.
> 
> That said, the fixes are only meaningful if we do need to restrict channels to a specific
> buffer. Not sure if that will be the case here.

Without design changes, that is exactly the case. A triggered buffer
for the RAM control channel, and a DMA engine buffer for the parallel port
channel.

-- 
Kind regards,

Rodrigo Alencar