Re: [PATCH v2 1/9] dt-bindings: iio: dac: ad3552r: add io-backend property

["Nuno Sá" <noname.nuno@gmail.com>]

On Mon, 2024-09-09 at 17:06 +0100, Conor Dooley wrote:
> On Mon, Sep 09, 2024 at 04:03:17PM +0200, Nuno Sá wrote:
> > On Mon, 2024-09-09 at 13:46 +0100, Conor Dooley wrote:
> > > On Sun, Sep 08, 2024 at 01:29:25PM +0100, Jonathan Cameron wrote:
> 
> > > I'd also really like to know how this fits in with spi-offloads. It
> > > /feels/, and I'd like to reiterate the word feels, like a rather similar
> > > idea just applied to a DAC instead of an ADC.
> > 
> > The offload main principle is to replay a spi transfer periodically given an
> > input trigger. I'm not so sure we have that same principle in here. In here
> > I
> > guess we stream data over the qspi interface based on SCLK which can look
> > similar. The difference is that this IP does not need any trigger for any
> > spi
> > transfer replay (I think). 
> 
> Right, if the trigger part is what decides it for you then I'm wildin
> here.

I mean, not only the trigger. These IPs (axi-dac/adc) are meant to deal with
data while in theory the spi offload principle is about replaying any spi
transfers. But yeah, the above reasoning does not make sense as a data transfer
is still a transfer.

FWIW, these IPs are inherently offload HW as their goal is really to stream data
without any SW intervention (so called HW_BUFFERING in IIO world). Just that
typically you have LVDS/CMOS data interfaces and now we have a qspi interface
and a spi-offload concept already introduced. 

So, yeah, as we want to have spi-offloads documented in the bindings, we can
also document this setup with the same bindings.

- Nuno Sá