From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30EEE58115 for ; Thu, 11 Jan 2024 20:54:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="tOE4yu9j" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-50e7dd8bce8so6778814e87.1 for ; Thu, 11 Jan 2024 12:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1705006460; x=1705611260; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ylEjVhaN7U3+Tq2GKvOYEoSFBqgDAhHQ3vUsYifSnC4=; b=tOE4yu9j+QLc7Wfki9AdGF44qj/iBWUFqM5ZJFsNQWpL1WpJ9+s3K7Ri5MlTd3Y6jq +cACdkIVhIkWTYuKL8gGHNSyya5Ri38og5XVz5o5nZVsACpNXrh2QqPen/5QpAW9rEIs EHDeFMfGkMS1UCCp2iMQF/l4IHdn1FlrBmWNOJIJdFcnmeG9VOflgBSEUOfffReeITWN YHSd569no6sBeGMpzPFdD4PE+ur3iK44dU82ArHwN2UxAFsfX9NnPcc83DmlhL21q+pV CkTazHLJTSaR49NTfSI8RzukrT7pIQuFMd17mLouR5e85ev1Jlj9O2JzRm3CIyOQV/Yb kV6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705006460; x=1705611260; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ylEjVhaN7U3+Tq2GKvOYEoSFBqgDAhHQ3vUsYifSnC4=; b=VMB92fllJZCZpZYI+J1B8ILsfcwcWKXu0pspnBc97Bw8Z11vi6biuP10VrX7OPeGcU xXR4d/u9+z447pV/Iwk/Orz/X3e/lAbc29Q1CCm3Goubp4kVjxHQd8XWvc1YE3lprkz7 ksVycCxAuymBgLLNkr9yYVrSDWxTqetBLfijmxRtnwhhImrdUR47dwDA9R1FOzQSLjjK durhT7wB6Bs9IHLRQcbk1U7oTD3GUW1cMPXOnTzBzFB7YSWv4mrOen14s4iFhfxkIFxJ DPMAw/Dm3m3tNhqWMBls2uioxTC+cs48xefKzFpyFgN2Ohz0dxnbaProRJgH7NJPjozn cmPw== X-Gm-Message-State: AOJu0YxoL6ckVa/pcav0AgS7xC/UTtpYbJqjtzvZeaXTsl1sIdZhmhht SyOCdAMfmSSg0Nr5Obg81u77q3/LTi1Ar6A4DMFvB1Y9SbVcwg== X-Google-Smtp-Source: AGHT+IEWzwr/tc2fYB85wLIF4FNfK9wFIyN4eyOO2fYyS4zfclc3IVSwHz7GtBfcfd6NENCzsVQn8Z5BmbvtojGy7fo= X-Received: by 2002:a05:6512:3f04:b0:50e:dc80:d560 with SMTP id y4-20020a0565123f0400b0050edc80d560mr156153lfa.45.1705006460198; Thu, 11 Jan 2024 12:54:20 -0800 (PST) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240109-axi-spi-engine-series-3-v1-0-e42c6a986580@baylibre.com> <20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com> <2c74aad9-3cb9-4222-8072-e72120c2658e@sirena.org.uk> In-Reply-To: <2c74aad9-3cb9-4222-8072-e72120c2658e@sirena.org.uk> From: David Lechner Date: Thu, 11 Jan 2024 14:54:09 -0600 Message-ID: Subject: Re: [PATCH 01/13] spi: add core support for controllers with offload capabilities To: Mark Brown Cc: Jonathan Cameron , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Hennerich , =?UTF-8?B?TnVubyBTw6E=?= , Frank Rowand , Thierry Reding , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Jonathan Corbet , 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, David Jander Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2024 at 3:36=E2=80=AFPM Mark Brown wro= te: > > On Wed, Jan 10, 2024 at 01:49:42PM -0600, David Lechner wrote: > > This adds a feature for specialized SPI controllers that can record > > a series of SPI transfers, including tx data, cs assertions, delays, > > etc. and then play them back using a hardware trigger without CPU > > intervention. > > > The intended use case for this is with the AXI SPI Engine to capture > > data from ADCs at high rates (MSPS) with a stable sample period. > > > Most of the implementation is controller-specific and will be handled b= y > > drivers that implement the offload_ops callbacks. The API follows a > > prepare/enable pattern that should be familiar to users of the clk > > subsystem. > > This is a lot to do in one go, and I think it's a bit too off on the > side and unintegrated with the core. There's two very high level bits > here, there's the pre-cooking a message for offloading to be executed by > a hardware engine and there's the bit where that's triggered by some > hardwar event rather than by software. > > There was a bunch of discussion of the former case with David Jander I found [1] which appears to be the conversation you are referring to. Is that all or is there more that I missed? [1]: https://lore.kernel.org/linux-spi/20220512163445.6dcca126@erd992/ > (CCed) a while back when he was doing all the work he did on optimising > the core for uncontended uses, the thinking there was to have a > spi_prepare_message() (or similar) API that drivers could call and then > reuse the same transfer repeatedly, and even without any interface for > client drivers it's likely that we'd be able to take advantage of it in > the core for multi-transfer messages. I'd be surprised if there weren't > wins when the message goes over the DMA copybreak size. A much wider > range of hardware would be able to do this bit, for example David's case > was a Raspberry Pi using the DMA controller to write into the SPI > controller control registers in order to program it for multiple > transfers, bounce chip select and so on. You could also use the > microcontroller cores that many embedded SoCs have, and even with zero > hardware support for offloading anything there's savings in the message > validation and DMA mapping. > I can see how such a spi_prepare_message() API could be useful in general and would be a good first step towards what we are wanting to accomplish too. For example, in the IIO subsystem, it is a common pattern when using a triggered buffer to prepare some spi xfer structs in the buffer setup phase that get reused multiple times. So this could, as you said, at least save the overhead of validating/mapping the same xfers over and over. I will look into this first and then we can come back to the second part about hardware triggers once that is done.