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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a8941a316a96be620a058be853b55923ab51fb5b.camel@gmail.com>
Date: Tue, 10 Sep 2024 10:12:36 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Conor Dooley <conor@...nel.org>
Cc: Conor Dooley <conor.dooley@...rochip.com>, Jonathan Cameron
 <jic23@...nel.org>, Angelo Dureghello <adureghello@...libre.com>,
 Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Nuno Sá
 <nuno.sa@...log.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Olivier Moysan
 <olivier.moysan@...s.st.com>, linux-iio@...r.kernel.org, 
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, David Lechner
 <dlechner@...libre.com>
Subject: Re: [PATCH v2 1/9] dt-bindings: iio: dac: ad3552r: add io-backend
 property

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á