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

[David Lechner]

On 3/10/26 12:40 PM, Rodrigo Alencar wrote:
> 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)

Have you looked at firmware_upload_register()? It looks like it provides
something along these lines.

> - 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.
>