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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
