[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230416152422.477ecf67@jic23-huawei>
Date: Sun, 16 Apr 2023 15:24:22 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Paul Cercueil <paul@...pouillou.net>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Vinod Koul <vkoul@...nel.org>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Nuno Sá <noname.nuno@...il.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
linux-iio@...r.kernel.org, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v3 03/11] iio: buffer-dma: Get rid of outgoing queue
On Mon, 3 Apr 2023 17:47:52 +0200
Paul Cercueil <paul@...pouillou.net> wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
>
> Since the new DMABUF based API wouldn't use the outgoing queue anyway,
> getting rid of it now makes the upcoming changes simpler.
>
> With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
> be removed.
>
> Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>
> ---
> v2: - Only remove the outgoing queue, and keep the incoming queue, as we
> want the buffer to start streaming data as soon as it is enabled.
> - Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the
> same as IIO_BLOCK_STATE_DONE.
I'm not that familiar with this code, but with my understanding this makes
sense. I think it is independent of the earlier patches and is a useful
change in it's own right. As such, does it make sense to pick this up
ahead of the rest of the series? I'm assuming that discussion on the
rest will take a while. No great rush as too late for the coming merge
window anyway.
Thanks,
Jonathan
Powered by blists - more mailing lists