Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp895749pxb; Sun, 21 Feb 2021 04:14:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAMcVihO2Rm8bQotUUMdqPSANhQ17fNqShrkcbkMGwvwO81vfEGLBJTpLGpvryutUiS6N0 X-Received: by 2002:a05:6402:424a:: with SMTP id g10mr17737473edb.236.1613909643895; Sun, 21 Feb 2021 04:14:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613909643; cv=none; d=google.com; s=arc-20160816; b=XXFUcGfkkU+nzBtyMtYGvBpMG8tiQl3q2cL8m79j7BPEAgwtFFAzX0JLKO5Odxy0em OcHSUr232SN7QiixNHETUaU7Wwa+nUAgmERx8/dbqPRPkD9aXj0rWpb+XQd2NqsHxunu l938al9iD0oJRQdMYECb6XjdpfoAjQL3TnRMHj9MKxixlhBnlRX7ewP4lJcDyJOaIKFG kuzS7ayWtj/s5PxE8PmI/5e4eejT7zYX2yNpnWPkjjAsNMIMO35vXC+B7vL482p5I6RY Axp1/7N3VJOWo/2s/nJXMJNZF2EX5o0taRDMv8qeAJ0W+u0BJ6EGbppnG0Qsxwqcl9TV 8OSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=BwI+SXJ5UWuzyaWs/kj8V/Do9qvKWnLdNvOrGJDljCI=; b=N+s8kvDdbZ6enH7bswUqQ/Mypf/+/b8BKLCDrbH2DWwX+P1qJigmG6rf5c19yRovJk 2FYIjSEQcalazbCXm+DoqT3JoE31ZbSH4yqRhMPz/Iz+AZWVBrQqTBZ2CUsY41xSVVf7 LPOO4HG/9E/JrGQ8OrgdXp26VHhUGpx+KNn5M9+htWiT1HJA9RnxF3iTpIfa1u5X6b/I 4rIyjDMtYRqrO5G1cXYP3bB2x4VwlDf7QD/rQzCVAFBHoEmXHIWu0N/jvpm0QaojaW6A NNa9xnXKyUuQh6okj69K0U4eGdyOJTLaEIIr84jwn3foYR/0232XHWdKFO9NCTgOnRH1 dIwQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m17si10410259edc.402.2021.02.21.04.13.40; Sun, 21 Feb 2021 04:14:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229871AbhBUMKr (ORCPT + 99 others); Sun, 21 Feb 2021 07:10:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:56886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbhBUMKo (ORCPT ); Sun, 21 Feb 2021 07:10:44 -0500 Received: from archlinux (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D8F996186A; Sun, 21 Feb 2021 12:10:01 +0000 (UTC) Date: Sun, 21 Feb 2021 12:09:58 +0000 From: Jonathan Cameron To: Alexandru Ardelean Cc: , , , , , Subject: Re: [PATCH v3 6/6] iio: buffer-dma: add support for cyclic DMA transfers Message-ID: <20210221120958.7623e02c@archlinux> In-Reply-To: <20210219124012.92897-7-alexandru.ardelean@analog.com> References: <20210219124012.92897-1-alexandru.ardelean@analog.com> <20210219124012.92897-7-alexandru.ardelean@analog.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Feb 2021 14:40:12 +0200 Alexandru Ardelean wrote: > From: Lars-Peter Clausen > > This change adds support for cyclic DMA transfers using the IIO buffer DMA > infrastructure. > To do this, userspace must set the IIO_BUFFER_BLOCK_FLAG_CYCLIC flag on the > block when enqueueing them via the ENQUEUE_BLOCK ioctl(). > > Signed-off-by: Lars-Peter Clausen > Signed-off-by: Alexandru Ardelean Series in general looks good to me, but this change needs a little more detail + probably some level of example userspace flow. I don't really understand how this is used! Also, it's easy to test output buffers with the kfifo support so we should be able to move forward quickly with that part (1-3, 4 is probably fine as well as clearly harmless). The dma stuff worries me more, at least partly based on the experience of the original dma buffers which basically sat their unused (in upstream) for a very long time. So to move these forward, they need to come with users... Thanks, Jonathan > --- > .../buffer/industrialio-buffer-dmaengine.c | 24 ++++++++++++------- > include/uapi/linux/iio/buffer.h | 1 + > 2 files changed, 17 insertions(+), 8 deletions(-) > > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c > index 65458a6cc81a..39cc230c7991 100644 > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c > @@ -82,14 +82,22 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue, > > direction = dmaengine_buffer->is_tx ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM; > > - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan, > - block->phys_addr, block->block.bytes_used, direction, > - DMA_PREP_INTERRUPT); > - if (!desc) > - return -ENOMEM; > - > - desc->callback_result = iio_dmaengine_buffer_block_done; > - desc->callback_param = block; > + if (block->block.flags & IIO_BUFFER_BLOCK_FLAG_CYCLIC) { > + desc = dmaengine_prep_dma_cyclic(dmaengine_buffer->chan, > + block->phys_addr, block->block.bytes_used, > + block->block.bytes_used, direction, 0); > + if (!desc) > + return -ENOMEM; > + } else { > + desc = dmaengine_prep_slave_single(dmaengine_buffer->chan, > + block->phys_addr, block->block.bytes_used, direction, > + DMA_PREP_INTERRUPT); > + if (!desc) > + return -ENOMEM; > + > + desc->callback_result = iio_dmaengine_buffer_block_done; > + desc->callback_param = block; > + } > > cookie = dmaengine_submit(desc); > if (dma_submit_error(cookie)) > diff --git a/include/uapi/linux/iio/buffer.h b/include/uapi/linux/iio/buffer.h > index 4e4ee9befea1..1bde508fe1b9 100644 > --- a/include/uapi/linux/iio/buffer.h > +++ b/include/uapi/linux/iio/buffer.h > @@ -33,6 +33,7 @@ struct iio_buffer_block_alloc_req { > > /* A function will be assigned later for BIT(0) */ > #define IIO_BUFFER_BLOCK_FLAG_RESERVED (1 << 0) > +#define IIO_BUFFER_BLOCK_FLAG_CYCLIC (1 << 1) > > /** > * struct iio_buffer_block - Descriptor for a single IIO block