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á
