From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61A08364935; Sun, 17 May 2026 12:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779020739; cv=none; b=GTjSd9mSQPyACqp4nTuoRi6m1MwZIM3S2rIG8KUeUgzf5JZabpReu7l2LE8f2HzkgBc1V14lMHh/RafgmiMbt9BpinjkspBKqoZH4XYm+U4D1Ropco7mrNK6j1XXg9qfq8OzGVKK0uurFoToqkx8oQeqZ5Dh//4va2b8kIeL2V0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779020739; c=relaxed/simple; bh=XSkWEDKw02puX5qq9iVXr5jO9QBcF6MO0A6mYsf1hdE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dnghgpROWLC4u3g+M3TuxyfH9YwCum+0qrJvoxCzmbvhTZT0S08f/jlr6IqNwB1cnMhF1eNn60Sv7e0ud6G3/XkDFackMDbP6+lxcpl7uD3KcLGaBk6O1632Wf1bObDZWuoGCNZDtuj6m1zjgbm87LrwPtvIMHOPvIQdEjfxtFI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EZAIcCP7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EZAIcCP7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1D06C2BCB0; Sun, 17 May 2026 12:25:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779020738; bh=XSkWEDKw02puX5qq9iVXr5jO9QBcF6MO0A6mYsf1hdE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EZAIcCP7v4Ac0pHIPolzYXkoyEpgmNqJuYvvoCfXRzGhU48cxxNog+zKms+IJtyQ8 qiHSWt2RbE+p7qFLGY0zIT9kJWZNDIf+QEyS7xStQacOhcwwLtSkktiq/yfqjHL4ic vm4tu1Sdmud0fcfd4AQRs2/2oI1aFkOkDyGARhbXwEqJ2PplwVU3KKMP8RZkGWTJti poTy161sTSD2Z59gKnCwwzgt/brsxmfKFga7GqkNlou83OpWHqlzvX8ed+jpKmxzSz AH9xUuYP4J6X7FbRUA2JZ5xVspn2tO7VNW4HQM+YAPuFLJdXwiUX95R244DCdo+m1G IveIOhBeg0iPg== Date: Sun, 17 May 2026 13:25:26 +0100 From: Jonathan Cameron To: David Lechner Cc: radu.sabau@analog.com, Lars-Peter Clausen , Michael Hennerich , Nuno =?UTF-8?B?U8Oh?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= , Liam Girdwood , Mark Brown , Linus Walleij , Bartosz Golaszewski , Philipp Zabel , Jonathan Corbet , Shuah Khan , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v11 3/6] iio: adc: ad4691: add triggered buffer support Message-ID: <20260517132526.27c71b70@jic23-huawei> In-Reply-To: <9b7986e1-6550-415d-b301-33089ba10177@baylibre.com> References: <20260515-ad4692-multichannel-sar-adc-driver-v11-0-eab27d852ac2@analog.com> <20260515-ad4692-multichannel-sar-adc-driver-v11-3-eab27d852ac2@analog.com> <9b7986e1-6550-415d-b301-33089ba10177@baylibre.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 16 May 2026 12:32:51 -0500 David Lechner wrote: > On 5/15/26 8:31 AM, Radu Sabau via B4 Relay wrote: > > From: Radu Sabau > >=20 > > Add buffered capture support using the IIO triggered buffer framework. > >=20 > > CNV Burst Mode: the GP pin identified by interrupt-names in the device > > tree is configured as DATA_READY output. The IRQ handler stops > > conversions and fires the IIO trigger; the trigger handler executes a > > pre-built SPI message that reads all active channels from the AVG_IN > > accumulator registers and then resets accumulator state and restarts > > conversions for the next cycle. > >=20 > > Manual Mode: CNV is tied to SPI CS so each transfer simultaneously > > reads the previous result and starts the next conversion (pipelined > > N+1 scheme). At preenable time a pre-built, optimised SPI message of > > N+1 transfers is constructed (N channel reads plus one NOOP to drain > > the pipeline). The trigger handler executes the message in a single > > spi_sync() call and collects the results. An external trigger (e.g. > > iio-trig-hrtimer) is required to drive the trigger at the desired > > sample rate. > >=20 > > Both modes share the same trigger handler and push a complete scan =E2= =80=94 > > one big-endian 16-bit (__be16) slot per active channel, densely packed > > in scan_index order, followed by a timestamp. > >=20 > > The CNV Burst Mode sampling frequency (PWM period) is exposed as a > > buffer-level attribute via IIO_DEVICE_ATTR. > >=20 > > Signed-off-by: Radu Sabau > > + > > +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev) > > +{ > > + struct ad4691_state *st =3D iio_priv(indio_dev); > > + unsigned int k, i; > > + int ret; > > + > > + memset(st->scan_xfers, 0, sizeof(st->scan_xfers)); > > + memset(st->scan_tx, 0, sizeof(st->scan_tx)); > > + > > + spi_message_init(&st->scan_msg); > > + > > + k =3D 0; > > + iio_for_each_active_channel(indio_dev, i) { > > + if (i >=3D indio_dev->num_channels - 1) > > + break; /* skip soft timestamp */ =20 >=20 > I don't think timestamp gets set in the scan mask. It is handled separate= ly. FWIW that is a sashiko false postive (I believe anyway!) If we do hit this please shout as we have a core bug. If anyone has time to look at how hard it would be to tweak iio_for_each_active_channel to skip a last element timestamp that would be great. I think that iterates one too far which is what sashiko is tripping over. I'm only keen to fix that if we can make it low cost and hid it entirely from drivers. Jonathan >=20 > > + /* > > + * Channel-select command occupies the first (high) byte of the > > + * 16-bit DIN frame; the second byte is a don't-care zero pad. > > + * put_unaligned_be16() writes [cmd, 0x00] in memory so the > > + * SPI controller sends the command byte first on the wire. > > + */ > > + put_unaligned_be16((u16)(AD4691_ADC_CHAN(i) << 8), &st->scan_tx[k]); > > + st->scan_xfers[k].tx_buf =3D &st->scan_tx[k]; > > + /* > > + * The pipeline means xfer[0] receives the residual from the > > + * previous sequence, not a valid sample. Discard it (rx_buf=3DNULL) > > + * to avoid aliasing vals[0] across two concurrent DMA mappings. > > + * xfer[1] (or the NOOP when only one channel is active) writes > > + * the real ch[0] result to vals[0]. Subsequent transfers write > > + * into vals[k-1] so each result lands at the next dense slot. > > + */ > > + st->scan_xfers[k].rx_buf =3D (k =3D=3D 0) ? NULL : &st->vals[k - 1]; > > + st->scan_xfers[k].len =3D sizeof(st->scan_tx[k]); > > + st->scan_xfers[k].cs_change =3D 1; > > + st->scan_xfers[k].cs_change_delay.value =3D AD4691_CNV_HIGH_TIME_NS; > > + st->scan_xfers[k].cs_change_delay.unit =3D SPI_DELAY_UNIT_NSECS; > > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg); > > + k++; > > + } > > + > > + /* Final NOOP transfer retrieves the last channel's result. */ > > + st->scan_xfers[k].tx_buf =3D &st->scan_tx[k]; /* scan_tx[k] =3D=3D 0 = =3D=3D NOOP */ > > + st->scan_xfers[k].rx_buf =3D &st->vals[k - 1]; > > + st->scan_xfers[k].len =3D sizeof(st->scan_tx[k]); > > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg); > > + > > + ret =3D spi_optimize_message(st->spi, &st->scan_msg); > > + if (ret) > > + return ret; > > + > > + ret =3D ad4691_enter_conversion_mode(st); > > + if (ret) { > > + spi_unoptimize_message(&st->scan_msg); > > + return ret; > > + } > > + > > + return 0; > > +}