From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
vinod.koul@intel.com, linux-kernel@vger.kernel.org,
tony@atomide.com, dmaengine@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/7] dmaengine: omap-dma: Complete the cookie first on transfer completion
Date: Wed, 20 Jul 2016 08:26:03 +0200 [thread overview]
Message-ID: <877fcg25c4.fsf@belgarion.home> (raw)
In-Reply-To: <923b54d6-c7fc-66c2-1c20-d8d74ebed912@ti.com> (Peter Ujfalusi's message of "Tue, 19 Jul 2016 15:35:18 +0300")
Peter Ujfalusi <peter.ujfalusi@ti.com> writes:
> On 07/18/16 13:34, Russell King - ARM Linux wrote:
>> On Thu, Jul 14, 2016 at 03:42:37PM +0300, Peter Ujfalusi wrote:
>>> Before looking for the next descriptor to start, complete the just finished
>>> cookie.
>>
>> This change will reduce performance as we no longer have an overlap
>> between the next request starting to be dealt with in the hardware
>> vs the previous request being completed.
>
> 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.
>
> 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.
Euh actually I think it's done in other drivers as well :
- Documentation/dmaengine/pxa_dma.txt (chapter "Transfers hot-chaining)
- drivers/dma/pxa_dma.c
=> look for pxad_try_hotchain() and it's impact on pxad_chan_handler() which
will mark the completion while the next transfer is already pumped by the
hardware.
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.
So in your quest for the "better sequence" the pxa driver's one might give you
some perspective :)
Cheers.
--
Robert
next prev parent reply other threads:[~2016-07-20 6:26 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 [this message]
2016-07-21 9:33 ` Peter Ujfalusi
2016-07-21 9:35 ` Peter Ujfalusi
2016-07-21 9:47 ` Russell King - ARM Linux
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=877fcg25c4.fsf@belgarion.home \
--to=robert.jarzmik@free.fr \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=peter.ujfalusi@ti.com \
--cc=tony@atomide.com \
--cc=vinod.koul@intel.com \
/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