Received-SPF: pass (google.com: domain of linux-kernel+bounces-196410-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <32747c84d382d5c24408bcceb885659d28f20585.camel@gmail.com>
Subject: Re: [PATCH RFC v2 1/8] spi: dt-bindings: spi-peripheral-props: add
 spi-offloads property
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: David Lechner <dlechner@baylibre.com>, Conor Dooley <conor@kernel.org>
Cc: Mark Brown <broonie@kernel.org>, Jonathan Cameron <jic23@kernel.org>, 
 Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>,
 Conor Dooley <conor+dt@kernel.org>,  Nuno =?ISO-8859-1?Q?S=E1?=
 <nuno.sa@analog.com>, Michael Hennerich <Michael.Hennerich@analog.com>, 
 Lars-Peter Clausen <lars@metafoo.de>, David Jander <david@protonic.nl>,
 Martin Sperl <kernel@martin.sperl.org>, linux-spi@vger.kernel.org, 
 devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, 
 linux-iio@vger.kernel.org
Date: Fri, 31 May 2024 09:33:44 +0200
In-Reply-To: <6db8ba66-841b-4425-9dd4-9d6e7b0463bf@baylibre.com>
References: <20240513-headsman-hacking-d51fcc811695@spud>
	 <CAMknhBE5XJzhdJ=PQUXiubw_CiCLcn1jihiscnQZUzDWMASPKw@mail.gmail.com>
	 <20240514-aspire-ascension-449556da3615@spud>
	 <CAMknhBFFpEGcMoLo5gsC11Syv+CwUM0mnq1yDMUzL1uutUtB+Q@mail.gmail.com>
	 <20240516-rudder-reburial-dcf300504c0a@spud>
	 <CAMknhBF_s0btus4yqPe-T=F3z7Asi9KkRGsGr7FHDFi=k4EQjw@mail.gmail.com>
	 <20240519-abreast-haziness-096a57ef57d3@spud>
	 <CAMknhBHvEse2FyDoBXR1PvymGpSGq8dotKfm+8XH+0+k+xKtQw@mail.gmail.com>
	 <20240522-gullible-ibuprofen-cf9111c25f6f@spud>
	 <5ad0b5782434eaf4cf565cffb0e4c14b7414ae38.camel@gmail.com>
	 <20240526-peculiar-panama-badda4f02336@spud>
	 <10991373cb9603803df63d8236c475807f6dde68.camel@gmail.com>
	 <6db8ba66-841b-4425-9dd4-9d6e7b0463bf@baylibre.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.1 (3.52.1-1.fc40) 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-05-30 at 14:24 -0500, David Lechner wrote:
> On 5/29/24 3:07 AM, Nuno S=C3=A1 wrote:
> > On Sun, 2024-05-26 at 18:35 +0100, Conor Dooley wrote:
>=20
>=20
> > > It might be easy to do it this way right now, but be problematic for =
a
> > > future device or if someone wants to chuck away the ADI provided RTL =
and
> > > do their own thing for this device. Really it just makes me wonder if
> > > what's needed to describe more complex data pipelines uses an of_grap=
h,
> > > just like how video pipelines are handled, rather than the implementa=
tion
> > > of io-backends that don't really seem to model the flow of data.
> > >=20
> >=20
> > Yeah, backends is more for devices/soft-cores that extend the functiona=
lity of
> > the
> > device they are connected too. Like having DACs/ADCs hdl cores for conn=
ecting to
> > high
> > speed controllers. Note that in some cases they also manipulate or even=
 create
> > data
> > but since they fit in IIO, having things like the DMA property in the h=
dl binding
> > was
> > fairly straight.
> >=20
> > Maybe having an offload dedicated API (through spi) to get/share a DMA =
handle
> > would
> > be acceptable. Then we could add support to "import" it in the IIO core=
 Then it
> > would be up to the controller to accept or not to share the handle (in =
some cases
> > the
> > controller could really want to have the control of the DMA transfers).
>=20
> I could see this working for some SPI controllers, but for the AXI SPI En=
gine
> + DMA currently, the DMA has a fixed word size, so can't be used as a gen=
eric
> DMA with arbitrary SPI xfers. For example, if the HDL is compiled with a =
32-bit
> word size, then even if we are reading 16-bit sample data, the DMA is goi=
ng to
> put it in a 32-bit slot. So one could argue that this is still doing some=
 data
> manipulation similar to the CRC checker example.
>=20

Note that what I was thinking was something very trivial... Just a way to g=
et
'dma_chan' out of the spi_engine to the consumer so we could import it in t=
he IIO DMA
infrastructure... I assume it may be a sneaky way to just get around the pr=
oblem
though :).

Another way is to come up with spi like API's to submit DMA request's (pass=
ing an
handler or so for completion). I guess we would somehow also need a kind of=
 get()
function that would give consumers some kind of info/interface like spi xfe=
rs size
(as in this particular case it's the DMA who defines the src/dst width). We=
 would
likely also need some kind of spi_dma_buffer implementation in IIO (likely =
to share
some code with the current stuff; at least the userspace interface should d=
efinitely
be the same).

Anyways, the above it's just me throwing some random ideas that come to min=
d :). They
may be stupid but at the very least they could give you some betters ideas =
:).

> >=20
> > Not familiar enough with of_graph so can't argue about it but likely is=
 something
> > worth looking at.
> >=20
> > - Nuno S=C3=A1
> > > >=20
>=20
> I did try implementing something using graph bindings when I first starte=
d
> working on this, but it didn't seem to really give us any extra useful
> information. It was just describing connections (endpoints) that I though=
t
> we could just implicitly assume. After this discussion though, maybe wort=
h
> a second look. I'll have to think about it more.

Why not :)?

- Nuno S=C3=A1