summaryrefslogtreecommitdiff
path: root/Documentation/dmaengine/provider.txt
AgeCommit message (Collapse)Author
2016-11-14dmaengine: Documentation: Fix typo in provider.txtVinod Koul
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-08-08dmaengine: documentation to the new callback mechanismDave Jiang
Adding documentation in dmaengine/provider.txt on the usage of callback with result, callback_result, function pointer to retrieve transanction result from a DMA submission. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-06-03Documentation: dmaengine: fix typo for device_resumeNiklas Söderlund
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2015-11-16dmaengine: Add transfer termination synchronization supportLars-Peter Clausen
The DMAengine API has a long standing race condition that is inherent to the API itself. Calling dmaengine_terminate_all() is supposed to stop and abort any pending or active transfers that have previously been submitted. Unfortunately it is possible that this operation races against a currently running (or with some drivers also scheduled) completion callback. Since the API allows dmaengine_terminate_all() to be called from atomic context as well as from within a completion callback it is not possible to synchronize to the execution of the completion callback from within dmaengine_terminate_all() itself. This means that a user of the DMAengine API does not know when it is safe to free resources used in the completion callback, which can result in a use-after-free race condition. This patch addresses the issue by introducing an explicit synchronization primitive to the DMAengine API called dmaengine_synchronize(). The existing dmaengine_terminate_all() is deprecated in favor of dmaengine_terminate_sync() and dmaengine_terminate_async(). The former aborts all pending and active transfers and synchronizes to the current context, meaning it will wait until all running completion callbacks have finished. This means it is only possible to call this function from non-atomic context. The later function does not synchronize, but can still be used in atomic context or from within a complete callback. It has to be followed up by dmaengine_synchronize() before a client can free the resources used in a completion callback. In addition to this the semantics of the device_terminate_all() callback are slightly relaxed by this patch. It is now OK for a driver to only schedule the termination of the active transfer, but does not necessarily have to wait until the DMA controller has completely stopped. The driver must ensure though that the controller has stopped and no longer accesses any memory when the device_synchronize() callback returns. This was in part done since most drivers do not pay attention to this anyway at the moment and to emphasize that this needs to be done when the device_synchronize() callback is implemented. But it also helps with implementing support for devices where stopping the controller can require operations that may sleep. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-08-17Documentation: dmaengine: Add DMA_CTRL_REUSE documentationVinod Koul
Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by:Robert Jarzmik <robert.jarzmik@free.fr>
2015-08-17Documentation: dmaengine: fix the DMA_CTRL_ACK documentationVinod Koul
As discussed recently the meaning of DMA_CTRL_ACK is that a desc cannot be reused by provider until the client acknowledges receipt, i.e. has has a chance to establish any dependency chains. So update documentation Signed-off-by: Vinod Koul <vinod.koul@intel.com> Acked-by:Robert Jarzmik <robert.jarzmik@free.fr>
2015-06-17Documentation: dmaengine: document DMA_CTRL_ACKRobert Jarzmik
Add documentation about acking the transfers, and their reusability. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-12-22Documentation: dmaengine: clarify dma_slave_config expectationsVinod Koul
dma_slave_config is expected to be set for slave operations Only, not for memcpy ones Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-12-22Documentation: dmaengine: Update the documentationMaxime Ripard
Now that we have splitted device_control and removed device_slave_caps in favor of a few dma_device variables, update the documentation accordingly. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-11-06Documentation: dmaengine: Add a documentation for the dma controller APIMaxime Ripard
The dmaengine is neither trivial nor properly documented at the moment, which means a lot of trial and error development, which is not that good for such a central piece of the system. Attempt at making such a documentation. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [fixed some minor typos] Signed-off-by: Vinod Koul <vinod.koul@intel.com>