Hi Jonathan,
Le dimanche 16 avril 2023 à 15:24 +0100, Jonathan Cameron a écrit :
On Mon, 3 Apr 2023 17:47:52 +0200 Paul Cercueil paul@crapouillou.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@crapouillou.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.
Actually, you can pick patches 3 to 6 (when all have been acked). They add write support for buffer-dma implementations; which is a dependency for the rest of the patchset, but they can live on their own.
Cheers, -Paul