Received-SPF: pass (google.com: domain of linux-kernel+bounces-201301-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 4 Jun 2024 20:42:55 +0100
From: Conor Dooley <conor@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Nuno =?iso-8859-1?Q?S=E1?= <noname.nuno@gmail.com>,
	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
Subject: Re: [PATCH RFC v2 1/8] spi: dt-bindings: spi-peripheral-props: add
 spi-offloads property
Message-ID: <20240604-awry-container-a8c12f421a81@spud>
References: <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>
 <20240604-oink-recognize-682c553a18e5@spud>
 <97246fdc-bb33-45bc-a24a-c2595920421f@baylibre.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="N7XUnDPkHiYJyKjd"
Content-Disposition: inline
In-Reply-To: <97246fdc-bb33-45bc-a24a-c2595920421f@baylibre.com>


--N7XUnDPkHiYJyKjd
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 04, 2024 at 02:39:18PM -0500, David Lechner wrote:
> On 6/4/24 2:33 PM, Conor Dooley wrote:
> > On Thu, May 30, 2024 at 02:24:17PM -0500, David Lechner wrote:
> >> On 5/29/24 3:07 AM, Nuno S=E1 wrote:
> >>> On Sun, 2024-05-26 at 18:35 +0100, Conor Dooley wrote:
> >>
> >>
> >>>> 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_gra=
ph,
> >>>> just like how video pipelines are handled, rather than the implement=
ation
> >>>> of io-backends that don't really seem to model the flow of data.
> >>>>
> >>>
> >>> Yeah, backends is more for devices/soft-cores that extend the functio=
nality of the
> >>> device they are connected too. Like having DACs/ADCs hdl cores for co=
nnecting to high
> >>> speed controllers. Note that in some cases they also manipulate or ev=
en create data
> >>> but since they fit in IIO, having things like the DMA property in the=
 hdl binding was
> >>> fairly straight.
> >>>
> >>> Maybe having an offload dedicated API (through spi) to get/share a DM=
A handle would
> >>> be acceptable. Then we could add support to "import" it in the IIO co=
re. Then it
> >>> would be up to the controller to accept or not to share the handle (i=
n some cases the
> >>> controller could really want to have the control of the DMA transfers=
).
> >>
> >> I could see this working for some SPI controllers, but for the AXI SPI=
 Engine
> >> + DMA currently, the DMA has a fixed word size, so can't be used as a =
generic
> >> 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 =
going to
> >> put it in a 32-bit slot. So one could argue that this is still doing s=
ome data
> >> manipulation similar to the CRC checker example.
> >>
> >>>
> >>> Not familiar enough with of_graph so can't argue about it but likely =
is something
> >>> worth looking at.
> >>
> >> I did try implementing something using graph bindings when I first sta=
rted
> >> working on this, but it didn't seem to really give us any extra useful
> >> information. It was just describing connections (endpoints) that I tho=
ught
> >> we could just implicitly assume. After this discussion though, maybe w=
orth
> >> a second look. I'll have to think about it more.
> >=20
> > Could you elaborate on why you think you can assume the connections? Wh=
at
> > happens when you have multiple stages of data processing and/or multiple
> > ADCs in your system? As I've previously said, I work on FPGA stuff, and
> > everyone here seems to fawn over having <insert custom DSP IP here> in
> > their data pipelines. I can't imagine it being any different for ADC da=
ta,
> > and an io-backend property that doesn't describe how the data flows is
> > gonna become lacklustre I think.
>=20
> I was more ignorant back then. :-)
>=20
> That is is why I said "thought" instead of "think". I am more enlightened=
 now.

Heh, I didn't mean it in a bad way. I just wanted to flesh out why you
thought that way.


--N7XUnDPkHiYJyKjd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZl9uPwAKCRB4tDGHoIJi
0gwfAP0Q76wab6QDgYXt0Men77yN9JCHnEby3Na84zUrczGQrwD/Xx9CS+IrehyC
9K6TFblM4VF6C/kX3HPENblvp8eKvw4=
=LGFO
-----END PGP SIGNATURE-----

--N7XUnDPkHiYJyKjd--