Received-SPF: pass (google.com: domain of linux-kernel+bounces-24873-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <96e211915fbc2cfb245a377e3ea6ddf3ef55d8f7.camel@gmail.com>
Subject: Re: [PATCH 06/13] iio: buffer: add hardware triggered buffer support
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: David Lechner <dlechner@baylibre.com>, Jonathan Cameron
	 <Jonathan.Cameron@huawei.com>
Cc: Mark Brown <broonie@kernel.org>, 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 17:50:50 +0100
In-Reply-To: <CAMknhBHs32nHH8o-m3ByFfiKGAY=U7is18LMM2tGhH-v4v+8EQ@mail.gmail.com>
References: 
	<20240109-axi-spi-engine-series-3-v1-0-e42c6a986580@baylibre.com>
	 <20240109-axi-spi-engine-series-3-v1-6-e42c6a986580@baylibre.com>
	 <20240112123711.0000422a@Huawei.com>
	 <CAMknhBHs32nHH8o-m3ByFfiKGAY=U7is18LMM2tGhH-v4v+8EQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Fri, 2024-01-12 at 09:42 -0600, David Lechner wrote:
> On Fri, Jan 12, 2024 at 6:37=E2=80=AFAM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >=20
> > On Wed, 10 Jan 2024 13:49:47 -0600
> > David Lechner <dlechner@baylibre.com> wrote:
> >=20
> > > This adds a new mode INDIO_HW_BUFFER_TRIGGERED to the IIO subsystem.
> > >=20
> > > This mode is essentially the hardware version of INDIO_BUFFER_TRIGGER=
ED
> > > where the trigger has the semantics of INDIO_HARDWARE_TRIGGERED and t=
he
> > > buffer has the semantics of INDIO_BUFFER_HARDWARE.
> > >=20
> > > So basically INDIO_HW_BUFFER_TRIGGERED is the same as
> > > INDIO_BUFFER_HARDWARE except that it also enables the trigger when th=
e
> > > buffer is enabled.
> >=20
> > If the trigger isn't routeable to multiple devices we normally don't
> > make it visible at all.
> >=20
> > I'm not yet understanding what a trigger actually means in this case.
> > Why do you need it to be userspace configurable?
> >=20
> > J
> >=20
>=20
> It looks like this question was answered in another thread (we need to
> configure the sampling frequency from userspace). But there you
> mentioned that adding a trigger for that seemed overkill. So you would
> you suggest to add the sampling_frequency sysfs attribute to the
> iio:deviceX instead and just forget about the trigger part? It seems a
> bit odd to me to have an attribute that may or may not be there
> depending other hardware external to the ADC chip. But if that is a
> normal acceptable thing to do, then it does seem like the simpler
> thing to do.

Well, for these converters you usually always need some sort of trigger to =
tell the
engine to fetch the data. But if not, you could make it optional in the dri=
ver (I
guess a trigger will always be a pwm, gpio, clk, etc...) and only expose th=
e
interface if needed. Yes, if we start having tons of devices with optional =
triggers
(which is not the case so far) I agree we would be duplicating logic all ov=
er the
place.

But let's see where all this discussion leads us. AFAIU, having the trigger=
s somehow
directly in the spi framework is also an option. If we can make that generi=
c enough
and with a nice interface I think that would make the most sense as this tr=
igger
affects the offload engine which is a spi controller thing. Let's see where=
 we end up
:)

- Nuno S=C3=A1