linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: DMA engine API issue
Date: Mon, 04 Aug 2014 20:03:45 +0200	[thread overview]
Message-ID: <53DFCB01.5050703@metafoo.de> (raw)
In-Reply-To: <1621896.RqTTnmY7rK@avalon>

On 08/04/2014 06:50 PM, Laurent Pinchart wrote:
[...]
>>>> from atomic context too.
>>>
>>> I'll take this opportunity to question why we have a separation between
>>> tx_submit and issue_pending. What's the rationale for that, especially
>>> given that dma_issue_pending_all() might kick in at any point and issue
>>> pending transfers for all devices. A driver could thus see its submitted
>>> but not issued transactions being issued before it explicitly calls
>>> dma_async_issue_pending().
>>
>> The  API states that you need to get a channel, then prepare a descriptor
>> and submit it back. Prepare can be in any order. The submit order is the one
>> which is run on dmaengine. The submit marks the descriptor as pending.
>> Typically you should have a pending_list which the descriptor should be
>> pushed to.
>>
>> And lastly invoke dma_async_issue_pending() to start the pending ones.
>>
>> You have the flexibility to prepare descriptors and issue in the order you
>> like. You can also attach the callback required for descriptors here.
>
> The question was why is there a dma_async_issue_pending() operation at all ?
> Why can't dmaengine_submit() triggers the transfer start ? The only
> explanation is a small comment in dmaengine.h that states
>
>   * This allows drivers to push copies to HW in batches,
>   * reducing MMIO writes where possible.
>
> I don't think that's applicable for DMA slave transfers. Is it still
> applicable for anything else ?
[...]

If the hardware has scatter gather support it allows the driver to chain the 
descriptors before submitting them, which reduces the latency between the 
transfers as well as the IO over overhead. The flaw with the current 
implementation is that there is only one global chain per channel instead of 
e.g. having the possibility to build up a chain in a driver and then submit and 
start the chain. Some drivers have virtual channels where each channel 
basically acts as the chain and once issue pending is called it is the chain is 
mapped to a real channel which then executes it.

- Lars

  reply	other threads:[~2014-08-04 18:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1406032431-3807-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
     [not found] ` <87d2cwvmxa.wl%kuninori.morimoto.gx@gmail.com>
     [not found]   ` <3361994.F0HgAeJkR9@avalon>
2014-07-23 11:07     ` DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support) Laurent Pinchart
2014-07-24  0:46       ` Kuninori Morimoto
2014-07-24  1:35         ` Kuninori Morimoto
2014-07-24  4:53           ` Vinod Koul
2014-07-24  4:52       ` Vinod Koul
2014-08-01  8:51         ` Laurent Pinchart
2014-08-01 14:30           ` Russell King - ARM Linux
2014-08-01 17:09             ` Vinod Koul
2014-08-04 13:47             ` Geert Uytterhoeven
2014-08-04 17:00             ` Laurent Pinchart
2014-08-04 17:54               ` Russell King - ARM Linux
2014-08-05 23:19                 ` Laurent Pinchart
2014-08-06  7:17                   ` Geert Uytterhoeven
2014-08-06 11:04                     ` Arnd Bergmann
2014-08-01 17:07           ` Vinod Koul
2014-08-04 16:50             ` Laurent Pinchart
2014-08-04 18:03               ` Lars-Peter Clausen [this message]
2014-08-04 18:32                 ` DMA engine API issue Russell King - ARM Linux
2014-08-04 23:12                   ` Laurent Pinchart
2014-08-05 16:56               ` DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support) Vinod Koul
2014-07-24 12:29       ` [alsa-devel] DMA engine API issue Lars-Peter Clausen
2014-07-24 12:51       ` DMA engine API issue (was: [PATCH/RFC 0/5] R-Car Gen2 DMAC hardware descriptor list support) Russell King - ARM Linux
2014-08-01  9:24         ` Laurent Pinchart

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=53DFCB01.5050703@metafoo.de \
    --to=lars@metafoo.de \
    --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).