From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/7] dmaengine: omap-dma: Complete the cookie first on transfer completion
Date: Thu, 21 Jul 2016 10:47:04 +0100 [thread overview]
Message-ID: <20160721094704.GL5783@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <f18ced07-39e4-c336-b788-254c2c130f82@ti.com>
On Thu, Jul 21, 2016 at 12:33:12PM +0300, Peter Ujfalusi wrote:
> On 07/20/16 09:26, Robert Jarzmik wrote:
> > Speaking of which, from a purely design point of view, as long as you think
> > beforehand what is your sequence, ie. what is the sequence of your link
> > chaining, completion handling, etc ..., both marking before or after next tx
> > start should be fine IMHO.
>
> Yes, it might be a bit better from performance point of view if we first start
> the pending descriptor (if there is one) then do the vchan_cookie_complete().
> On the other hand if we care more about latency and accuracy we should
> complete the transfer first then look for pending descriptors. But since
> virt_dma is using a tasklet for the real completion, the latency is always
> going to be when the tasklet is given the chance to execute.
I think this shows a slight misunderstanding of the DMA engine API. The
DMA completion is defined by the API to always happen in tasklet context,
which is why the virt-dma stuff does it that way - and all other DMA
engine drivers. It's one of the fundamentals of the API.
As it happens in tasklet context, tasklets can be scheduled to run with
variable latency, so any use of the DMA engine API which has a predictable
latency around the completion handling is going to be unreliable.
Remember also that with circular buffers, there's no guarantee of getting
period-based completion callbacks - several periods can complete and you
are only guaranteed to get one completion callback.
So, the idea that completion callbacks can have anything to do with low
latency or accuracy is totally incorrect.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2016-07-21 9:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 12:42 [PATCH 0/7] dmaengine:omap-dma: Linked List transfer for slave_sg Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 1/7] dmaengine: omap-dma: Simplify omap_dma_start_sg parameter list Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 2/7] dmaengine: omap-dma: Complete the cookie first on transfer completion Peter Ujfalusi
2016-07-18 10:34 ` Russell King - ARM Linux
2016-07-19 12:35 ` Peter Ujfalusi
2016-07-19 16:20 ` Russell King - ARM Linux
2016-07-19 19:23 ` Peter Ujfalusi
2016-07-24 7:39 ` Vinod Koul
2016-07-20 6:26 ` Robert Jarzmik
2016-07-21 9:33 ` Peter Ujfalusi
2016-07-21 9:35 ` Peter Ujfalusi
2016-07-21 9:47 ` Russell King - ARM Linux [this message]
2016-07-22 11:00 ` Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 3/7] dmaengine: omap-dma: Simplify omap_dma_callback Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 4/7] dmaengine: omap-dma: Dynamically allocate memory for lch_map Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 5/7] dmaengine: omap-dma: Add more debug information when freeing channel Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 6/7] dmaengine: omap-dma: Use pointer to omap_sg in slave_sg setup's loop Peter Ujfalusi
2016-07-14 12:42 ` [PATCH 7/7] dmaengine: omap-dma: Support for LinkedList transfer of slave_sg Peter Ujfalusi
2016-07-18 10:42 ` Russell King - ARM Linux
2016-07-18 11:12 ` Peter Ujfalusi
2016-07-18 10:31 ` [PATCH 0/7] dmaengine:omap-dma: Linked List transfer for slave_sg Russell King - ARM Linux
2016-07-18 12:07 ` Peter Ujfalusi
2016-07-18 12:21 ` Russell King - ARM Linux
2016-07-18 12:30 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160721094704.GL5783@n2100.arm.linux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).