On 07/19/2016 07:20 PM, Russell King - ARM Linux wrote:

quoted

vchan_cookie_complete() will only mark the cookie completed, adds the vd to
the desc_completed list (it was deleted from desc_issued list when it was
started by omap_dma_start_desc) and schedule the tasklet to deal with the real
completion later.
Marking the just finished descriptor/cookie done first then looking for
possible descriptors in the queue to start feels like a better sequence.

I deliberately arranged the code in the original order so that the next
transfer was started on the hardware with the least amount of work by
the CPU.  Yes, there may not be much in it, but everything you mention
above adds to the number of CPU cycles that need to be executed before
the next transfer can be started.

More CPU cycles wasted means higher latency between transfers, which
means lower performance.

OK. I will drop this patch in v2.

quoted

After a quick grep in the kernel source: only omap-dma.c was starting the
next transfer before marking the current completed descriptor/cookie done.

Right, because I've thought about the issue, having been the author of
both virt-dma and omap-dma.

-- 
P?ter