Received-SPF: pass (google.com: domain of linux-kernel+bounces-24378-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <fbe07c5f1d37febe0b89bf73816bc2e5d219547f.camel@gmail.com>
Subject: Re: [PATCH 01/13] spi: add core support for controllers with
 offload capabilities
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>, Jonathan Cameron
 <jic23@kernel.org>,  Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>,
 Michael Hennerich <michael.hennerich@analog.com>,  Nuno
 =?ISO-8859-1?Q?S=E1?= <nuno.sa@analog.com>, Frank Rowand
 <frowand.list@gmail.com>, Thierry Reding <thierry.reding@gmail.com>, Uwe
 =?ISO-8859-1?Q?Kleine-K=F6nig?= <u.kleine-koenig@pengutronix.de>, Jonathan
 Corbet <corbet@lwn.net>,  linux-spi@vger.kernel.org,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org, 
 linux-doc@vger.kernel.org, linux-pwm@vger.kernel.org, 
 linux-kernel@vger.kernel.org
Date: Fri, 12 Jan 2024 08:26:40 +0100
In-Reply-To: <ee19aa9e-cb51-41fb-a980-e3df579b5d35@sirena.org.uk>
References: 
	<20240109-axi-spi-engine-series-3-v1-0-e42c6a986580@baylibre.com>
	 <20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com>
	 <0c0b1954825dc174cab48060e96ddadadc18aefd.camel@gmail.com>
	 <aae36622-4e05-4f16-9460-d7614fd599aa@sirena.org.uk>
	 <5b62d742fa789e9860781b6f5f1fda4f583b0e5b.camel@gmail.com>
	 <ee19aa9e-cb51-41fb-a980-e3df579b5d35@sirena.org.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-01-11 at 15:41 +0000, Mark Brown wrote:
> On Thu, Jan 11, 2024 at 03:11:32PM +0100, Nuno S=C3=A1 wrote:
> > On Thu, 2024-01-11 at 13:33 +0000, Mark Brown wrote:
>=20
> > > I tend to agree that we shouldn't be exposing this to SPI device driv=
ers
> > > however we will want to keep track of if the unit is busy, and design=
ing
> > > it to cope with multiple offloads does seem like sensible future
> > > proofing.=C2=A0 There's also the possibility that one engine might be=
 able to
>=20
> > Fair enough. But wouldn't a simple DT integer property (handled by the =
spi core)
> > to identify the offload index be easier for SPI device drivers? We coul=
d still
> > have dedicated interfaces for checking if the unit is busy or not... Th=
e point
> > is that we would not need an explicit get() from SPI drivers.
>=20
> It feels like we'd need a get/release operation of some kind for mutual
> exclusion, it's not just the discovery it's also figuring out if the
> hardware is in use at a given moment.
>=20

Hmm did not thought about the busy case. Still, I could see this being easi=
ly done on
the controller driver (at least until we have a clear idea if this is usefu=
l or if it
will attract more users) or even at the spi core on the prepare + unprepare
interfaces. A flag could be enough to return EBUSY if someone is already in=
 the
process of preparing + enabling the engine.=C2=A0

Bah, anyways, it's just I'm really not thrilled about that kind of interfac=
e in here
but yeah, as long as you think it's worth it...
>=20

- Nuno S=C3=A1