summaryrefslogtreecommitdiff
path: root/Documentation/driver-api/dmaengine/provider.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-api/dmaengine/provider.rst')
-rw-r--r--Documentation/driver-api/dmaengine/provider.rst40
1 files changed, 24 insertions, 16 deletions
diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
index 0072c9c7efd3..1594598b3317 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -162,16 +162,6 @@ Currently, the types available are:
- The device is able to do memory to memory copies
-- - DMA_MEMCPY_SG
-
- - The device supports memory to memory scatter-gather transfers.
-
- - Even though a plain memcpy can look like a particular case of a
- scatter-gather transfer, with a single chunk to copy, it's a distinct
- transaction type in the mem2mem transfer case. This is because some very
- simple devices might be able to do contiguous single-chunk memory copies,
- but have no support for more complex SG transfers.
-
- No matter what the overall size of the combined chunks for source and
destination is, only as many bytes as the smallest of the two will be
transmitted. That means the number and size of the scatter-gather buffers in
@@ -182,8 +172,8 @@ Currently, the types available are:
- It's usually used for copying pixel data between host memory and
memory-mapped GPU device memory, such as found on modern PCI video graphics
cards. The most immediate example is the OpenGL API function
- ``glReadPielx()``, which might require a verbatim copy of a huge framebuffer
- from local device memory onto host memory.
+ ``glReadPixels()``, which might require a verbatim copy of a huge
+ framebuffer from local device memory onto host memory.
- DMA_XOR
@@ -206,6 +196,12 @@ Currently, the types available are:
- The device is able to perform parity check using RAID6 P+Q
algorithm against a memory buffer.
+- DMA_MEMSET
+
+ - The device is able to fill memory with the provided pattern
+
+ - The pattern is treated as a single byte signed value.
+
- DMA_INTERRUPT
- The device is able to trigger a dummy transfer that will
@@ -221,10 +217,12 @@ Currently, the types available are:
- DMA_ASYNC_TX
- - Must not be set by the device, and will be set by the framework
- if needed
+ - The device supports asynchronous memory-to-memory operations,
+ including memcpy, memset, xor, pq, xor_val, and pq_val.
- - TODO: What is it about?
+ - This capability is automatically set by the DMA engine
+ framework and must not be configured manually by device
+ drivers.
- DMA_SLAVE
@@ -437,6 +435,12 @@ supported.
- residue: Provides the residue bytes of the transfer for those that
support residue.
+- ``device_prep_peripheral_dma_vec``
+
+ - Similar to ``device_prep_slave_sg``, but it takes a pointer to a
+ array of ``dma_vec`` structures, which (in the long run) will replace
+ scatterlists.
+
- ``device_issue_pending``
- Takes the first transaction descriptor in the pending queue,
@@ -457,7 +461,7 @@ supported.
- Should use dma_set_residue to report it
- In the case of a cyclic transfer, it should only take into
- account the current period.
+ account the total size of the cyclic buffer.
- Should return DMA_OUT_OF_ORDER if the device does not support in order
completion and is completing the operation out of order.
@@ -548,6 +552,10 @@ dma_cookie_t
- Not really relevant any more since the introduction of ``virt-dma``
that abstracts it away.
+dma_vec
+
+- A small structure that contains a DMA address and length.
+
DMA_CTRL_ACK
- If clear, the descriptor cannot be reused by provider until the