Merge branch 'topic/xilinx' into fixes
Conflicts: Documentation/driver-api/dmaengine/provider.rst include/linux/dmaengine.h
This commit is contained in:
@@ -86,7 +86,9 @@ The details of these operations are:
|
||||
- interleaved_dma: This is common to Slave as well as M2M clients. For slave
|
||||
address of devices' fifo could be already known to the driver.
|
||||
Various types of operations could be expressed by setting
|
||||
appropriate values to the 'dma_interleaved_template' members.
|
||||
appropriate values to the 'dma_interleaved_template' members. Cyclic
|
||||
interleaved DMA transfers are also possible if supported by the channel by
|
||||
setting the DMA_PREP_REPEAT transfer flag.
|
||||
|
||||
A non-NULL return of this transfer API represents a "descriptor" for
|
||||
the given transaction.
|
||||
|
@@ -255,6 +255,27 @@ Currently, the types available are:
|
||||
identifier for each descriptor sent to the DMA device in order to
|
||||
properly track the completion.
|
||||
|
||||
- DMA_REPEAT
|
||||
|
||||
- The device supports repeated transfers. A repeated transfer, indicated by
|
||||
the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that
|
||||
it gets automatically repeated when it ends, but can additionally be
|
||||
replaced by the client.
|
||||
|
||||
- This feature is limited to interleaved transfers, this flag should thus not
|
||||
be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on
|
||||
the current needs of DMA clients, support for additional transfer types
|
||||
should be added in the future if and when the need arises.
|
||||
|
||||
- DMA_LOAD_EOT
|
||||
|
||||
- The device supports replacing repeated transfers at end of transfer (EOT)
|
||||
by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set.
|
||||
|
||||
- Support for replacing a currently running transfer at another point (such
|
||||
as end of burst instead of end of transfer) will be added in the future
|
||||
based on DMA clients needs, if and when the need arises.
|
||||
|
||||
These various types will also affect how the source and destination
|
||||
addresses change over time.
|
||||
|
||||
@@ -550,6 +571,34 @@ DMA_CTRL_REUSE
|
||||
writes for which the descriptor should be in different format from
|
||||
normal data descriptors.
|
||||
|
||||
- DMA_PREP_REPEAT
|
||||
|
||||
- If set, the transfer will be automatically repeated when it ends until a
|
||||
new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag.
|
||||
If the next transfer to be queued on the channel does not have the
|
||||
DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the
|
||||
client terminates all transfers.
|
||||
|
||||
- This flag is only supported if the channel reports the DMA_REPEAT
|
||||
capability.
|
||||
|
||||
- DMA_PREP_LOAD_EOT
|
||||
|
||||
- If set, the transfer will replace the transfer currently being executed at
|
||||
the end of the transfer.
|
||||
|
||||
- This is the default behaviour for non-repeated transfers, specifying
|
||||
DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference.
|
||||
|
||||
- When using repeated transfers, DMA clients will usually need to set the
|
||||
DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep
|
||||
repeating the last repeated transfer and ignore the new transfers being
|
||||
queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was
|
||||
stuck on the previous transfer.
|
||||
|
||||
- This flag is only supported if the channel reports the DMA_LOAD_EOT
|
||||
capability.
|
||||
|
||||
General Design Notes
|
||||
====================
|
||||
|
||||
|
Reference in New Issue
Block a user