From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 798D2318EC7; Mon, 4 May 2026 08:10:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777882216; cv=none; b=pdt5XofwlOOYPM9ZTc+HifgOdT56VRa3bvrvpm82UPWFiVuaf6YQqIMVDbXX+TIzFqVlQF/BiRKFNSbv7AOfIw162A+xqzXDiry6+Rvu487Ir2BB9WWE9iBcN4KhwfOnlYSPomuK0VkGcmSXjYDwK/kGS/Vk9Eo4b5XlttO21+k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777882216; c=relaxed/simple; bh=Aw2goGd/fJilo1nNYybeEo/I7OqMgACuWTjhFwMods4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oE17pItpnTYVDWVMpp7EhHXS7SSgwhGn0J7Ewjbs74/lyEflyol8UGCq+4BX3T6wTPaJVuHkv9jwQDV60QwX4KieGAA/8RFuOM8lhnQ+SbBvubj3v1VFUi/5Q0zILSMdtsLcyU++ig1qUPUX8CeO/nfnt+jKFRbXP8lDrTZp/ro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HVbea1nh; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HVbea1nh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777882214; x=1809418214; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=Aw2goGd/fJilo1nNYybeEo/I7OqMgACuWTjhFwMods4=; b=HVbea1nhIwye6rLGUk7aI/W/gORp6BcotpbuqM6ZIo7WRSAEtJcjXZbY KlqKKreXrVuNmdEBIfdVL9WiOjZvBLvkeja7evBdll8pAPTIhQZNr/HXV CKgus8K/C1UEiJPuosQnHiNnHS7aCBrFTL+oY2OsVKqBtDb0fxKJu4DCq 6b7sEzH2Zvf7rJroi9qytG1MyDalRh70LleOjOsXih/mqqeQV2iZj16QB GnUzMt9UT+dx0icNkkG7SKwn2Hu/J5eJVqqF4b6f1yjHM+NeC1y8itrJa o/9cmkyS+wTdvz2VASmBAD8mkhBzatryA76fzTdKOZg/VdfhSeWlVyPev Q==; X-CSE-ConnectionGUID: lLNcDu3cS6ebty0Nr8mHmA== X-CSE-MsgGUID: kRERN/alTxuSOSfQuYCQ6w== X-IronPort-AV: E=McAfee;i="6800,10657,11775"; a="78442661" X-IronPort-AV: E=Sophos;i="6.23,215,1770624000"; d="scan'208";a="78442661" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2026 01:10:13 -0700 X-CSE-ConnectionGUID: hreLLtATR/mogtrNmMDSBg== X-CSE-MsgGUID: Yh+aZY+rRpW8DxwXWoF2jQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,215,1770624000"; d="scan'208";a="235708240" Received: from hrotuna-mobl2.ger.corp.intel.com (HELO localhost) ([10.245.245.78]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2026 01:10:08 -0700 Date: Mon, 4 May 2026 11:10:05 +0300 From: Andy Shevchenko To: radu.sabau@analog.com Cc: Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , David Lechner , Nuno =?iso-8859-1?Q?S=E1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , 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 v9 4/6] iio: adc: ad4691: add SPI offload support Message-ID: References: <20260430-ad4692-multichannel-sar-adc-driver-v9-0-33e439e4fb87@analog.com> <20260430-ad4692-multichannel-sar-adc-driver-v9-4-33e439e4fb87@analog.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-4-33e439e4fb87@analog.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Thu, Apr 30, 2026 at 01:16:46PM +0300, Radu Sabau via B4 Relay wrote: > Add SPI offload support to enable DMA-based, CPU-independent data > acquisition using the SPI Engine offload framework. > > When an SPI offload is available (devm_spi_offload_get() succeeds), > the driver registers a DMA engine IIO buffer and uses dedicated buffer > setup operations. If no offload is available the existing software > triggered buffer path is used unchanged. > > Both CNV Burst Mode and Manual Mode support offload, but use different > trigger mechanisms: > > CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY > signal on the GP pin specified by the trigger-source consumer reference > in the device tree (one cell = GP pin number 0-3). For this mode the > driver acts as both an SPI offload consumer (DMA RX stream, message > optimization) and a trigger source provider: it registers the > GP/DATA_READY output via devm_spi_offload_trigger_register() so the > offload framework can match the '#trigger-source-cells' phandle and > automatically fire the SPI Engine DMA transfer at end-of-conversion. > > Manual Mode: the SPI Engine is triggered by a periodic trigger at > the configured sampling frequency. The pre-built SPI message uses > the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued > for N active channels (the first result is discarded as garbage from > the pipeline flush) and the remaining N results are captured by DMA. > > All offload transfers use 16-bit frames (bits_per_word=16, len=2). > The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared > between the software triggered-buffer and offload paths; no separate > scan_type or channel array is needed for the offload case. The > ad4691_manual_channels[] array introduced in the triggered-buffer > commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO > attribute, which is not applicable in Manual Mode. > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE. Unneeded detail in the commit message. It's visible from the patch. You probably wanted to explain "why?" it's required. ... > #include > #include > #include > +#include > +#include You missed at some point types.h (in this patch or earlier). > #include > #include ... > - /* max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */ > + /* > + * Non-offload: max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). > + * Offload reuses this array — both paths are mutually exclusive. > + */ Can you make sure this will be in the end result from the beginning, id est in the previous change put it as /* * Non-offload: max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). * Offload is not supported. */ OR /* * Non-offload: max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */ OR /* * max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */ This will minimize the churn. > struct spi_transfer scan_xfers[34]; ... > +static bool ad4691_offload_trigger_match(struct spi_offload_trigger *trigger, > + enum spi_offload_trigger_type type, > + u64 *args, u32 nargs) > +{ > + return type == SPI_OFFLOAD_TRIGGER_DATA_READY && > + nargs == 1 && args[0] <= 3; Seems there is a room in the previous line for more. > +} ... > - ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG, > - ~bitmap_read(indio_dev->active_scan_mask, 0, > - iio_get_masklength(indio_dev)) & GENMASK(15, 0)); > + acc_mask = ~bitmap_read(indio_dev->active_scan_mask, 0, > + iio_get_masklength(indio_dev)) & GENMASK(15, 0); > + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG, acc_mask); Make it like this in the previous patch. > if (ret) > goto err_unoptimize; ... > + offload = devm_kzalloc(dev, sizeof(*offload), GFP_KERNEL); Do you have device/devres.h already included (either explicitly or via device.h or platform_device.h)? > + if (!offload) > + return -ENOMEM; -- With Best Regards, Andy Shevchenko