summaryrefslogtreecommitdiffstats
path: root/Documentation/dmaengine.txt (follow)
Commit message (Collapse)AuthorAgeFilesLines
* dmaengine: Update documentation for inline wrapperGeert Uytterhoeven2014-08-281-2/+2
| | | | | | | | | | | | Commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave: introduce inline wrappers") introduced some wrappers, but there is still a reference to the old function. Update the documentation to use the wrapper, and add a missing "()" to a function name. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* dmaengine: Clarify device parameter for dma_sync_*_for_*()Geert Uytterhoeven2014-07-251-2/+4
| | | | | Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* dmaengine: Update documentation for inline wrappersGeert Uytterhoeven2014-07-141-6/+5
| | | | | | | | | | | | | | | | During the last few years, several inline wrappers for DMA operations have been introduced: - commit 16052827d98fbc13c31ebad560af4bd53e2b4dd5 ("dmaengine/dma_slave: introduce inline wrappers"), - commit a14acb4ac2a1486f6633c55eb7f7ded07f3ec9fc ("DMAEngine: add dmaengine_prep_interleaved_dma wrapper for interleaved api"), - commit 6e3ecaf0ad49de0bed829d409a164e7107c02993 ("dmaengine: add wrapper functions for device control functions"). Update the documentation to use the wrappers. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* Documentation: Fix multiple typo in DocumentationMasanari Iida2012-03-071-1/+1
| | | | | | Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* DMAEngine: Define interleaved transfer request apiJassi Brar2011-11-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | Define a new api that could be used for doing fancy data transfers like interleaved to contiguous copy and vice-versa. Traditional SG_list based transfers tend to be very inefficient in such cases as where the interleave and chunk are only a few bytes, which call for a very condensed api to convey pattern of the transfer. This api supports all 4 variants of scatter-gather and contiguous transfer. Of course, neither can this api help transfers that don't lend to DMA by nature, i.e, scattered tiny read/writes with no periodic pattern. Also since now we support SLAVE channels that might not provide device_prep_slave_sg callback but device_prep_interleaved_dma, remove the BUG_ON check. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Acked-by: Barry Song <Baohua.Song@csr.com> [renamed dmaxfer_template to dma_interleaved_template did fixup after the enum dma_transfer_merge] Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
* Improve slave/cyclic DMA engine documentationRussell King - ARM Linux2011-07-271-70/+164
| | | | | | | | | | | Improve the documentation for the slave and cyclic DMA engine support reformatting it for easier reading, adding further APIs, splitting it into five steps, and including references to the documentation in dmaengine.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [Fixed the index title to reflect new changes] Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* dmaengine: Add API documentation for slave dma usageVinod Koul2011-05-251-1/+96
| | | | | Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* async_tx, dmaengine: document channel allocation and api reworkDan Williams2009-01-061-0/+1
"Wouldn't it be better if the dmaengine layer made sure it didn't pass the same channel several times to a client? I mean, you seem concerned that the memcpy() API should be transparent and easy to use, but the whole registration interface is just ridiculously complicated..." - Haavard The dmaengine and async_tx registration/allocation interface is indeed needlessly complicated. This redesign has the following goals: 1/ Simplify reference counting: dma channels are not something one would expect to be hotplugged, it should be an exceptional event handled by drivers not something clients should be mandated to handle in a callback. The common case channel removal event is 'rmmod <dma driver>', which for simplicity should be disallowed if the channel is in use. 2/ Add an interface for requesting exclusive access to a channel suitable to device-to-memory users. 3/ Convert all memory-to-memory users over to a common allocator, the goal here is to not have competing channel allocation schemes. The only competition should be between device-to-memory exclusive allocations and the memory-to-memory usage case where channels are shared between multiple "clients". Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: Neil Brown <neilb@suse.de> Cc: Jeff Garzik <jeff@garzik.org> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>