Lines Matching +full:saw +full:- +full:slave
8 Most of the Slave DMA controllers have the same general principles of
20 DMA-eligible devices to the controller itself. Whenever the device
29 That wouldn't work well in the real world, since slave devices might
44 transfer into smaller sub-transfers.
49 non-contiguous buffers to a contiguous buffer, which is called
50 scatter-gather.
53 scatter-gather. So we're left with two cases here: either we have a
56 that implements in hardware scatter-gather.
72 not and the three parameters we saw earlier: the burst size, the
75 The one last thing is that usually, slave devices won't issue DRQ by
76 default, and you have to enable this in your slave device driver first
79 These were just the general memory-to-memory (also called mem2mem) or
80 memory-to-device (mem2dev) kind of transfers. Most devices often
98 documentation file in Documentation/crypto/async-tx-api.rst.
104 ------------------------------------
114 - ``channels``: should be initialized as a list using the
117 - ``src_addr_widths``:
120 - ``dst_addr_widths``:
123 - ``directions``:
124 should contain a bitmask of the supported slave directions
127 - ``residue_granularity``:
131 - Descriptor:
136 - Segment:
139 - Burst:
142 - ``dev``: should hold the pointer to the ``struct device`` associated
146 ---------------------------
161 - DMA_MEMCPY
163 - The device is able to do memory to memory copies
165 - DMA_XOR
167 - The device is able to perform XOR operations on memory areas
169 - Used to accelerate XOR intensive tasks, such as RAID5
171 - DMA_XOR_VAL
173 - The device is able to perform parity check using the XOR
176 - DMA_PQ
178 - The device is able to perform RAID6 P+Q computations, P being a
179 simple XOR, and Q being a Reed-Solomon algorithm.
181 - DMA_PQ_VAL
183 - The device is able to perform parity check using RAID6 P+Q
186 - DMA_INTERRUPT
188 - The device is able to trigger a dummy transfer that will
191 - Used by the client drivers to register a callback that will be
194 - DMA_PRIVATE
196 - The devices only supports slave transfers, and as such isn't
199 - DMA_ASYNC_TX
201 - Must not be set by the device, and will be set by the framework
204 - TODO: What is it about?
206 - DMA_SLAVE
208 - The device can handle device to memory transfers, including
209 scatter-gather transfers.
211 - While in the mem2mem case we were having two distinct types to
216 - If you want to transfer a single contiguous memory buffer,
219 - DMA_CYCLIC
221 - The device can handle cyclic transfers.
223 - A cyclic transfer is a transfer where the chunk collection will
226 - It's usually used for audio transfers, where you want to operate
229 - DMA_INTERLEAVE
231 - The device supports interleaved transfer.
233 - These transfers can transfer data from a non-contiguous buffer
234 to a non-contiguous buffer, opposed to DMA_SLAVE that can
235 transfer data from a non-contiguous data set to a continuous
238 - It's usually used for 2d content transfers, in which case you
242 - DMA_COMPLETION_NO_ORDER
244 - The device does not support in order completion.
246 - The driver should return DMA_OUT_OF_ORDER for device_tx_status if
249 - All cookie tracking and checking API should be treated as invalid if
252 - At this point, this is incompatible with polling option for dmatest.
254 - If this cap is set, the user is recommended to provide an unique
258 - DMA_REPEAT
260 - The device supports repeated transfers. A repeated transfer, indicated by
265 - This feature is limited to interleaved transfers, this flag should thus not
270 - DMA_LOAD_EOT
272 - The device supports replacing repeated transfers at end of transfer (EOT)
275 - Support for replacing a currently running transfer at another point (such
288 -------------------------------
300 - DESC_METADATA_CLIENT
307 - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM
313 - DMA_DEV_TO_MEM
320 - DESC_METADATA_ENGINE
329 - get_metadata_ptr()
334 - set_metadata_len()
344 -----------------
354 - ``device_alloc_chan_resources``
356 - ``device_free_chan_resources``
358 - These functions will be called whenever a driver will call
362 - They are in charge of allocating/freeing all the needed
365 - These functions can sleep.
367 - ``device_prep_dma_*``
369 - These functions are matching the capabilities you registered
372 - These functions all take the buffer or the scatterlist relevant
376 - These functions can be called from an interrupt context
378 - Any allocation you might do should be using the GFP_NOWAIT
382 - Drivers should try to pre-allocate any memory they might need
386 - It should return a unique instance of the
390 - This structure can be initialized using the function
393 - You'll also need to set two fields in this structure:
395 - flags:
399 - tx_submit: A pointer to a function you have to implement,
403 - In this structure the function pointer callback_result can be
411 - result: This provides the transfer result defined by
414 - residue: Provides the residue bytes of the transfer for those that
417 - ``device_issue_pending``
419 - Takes the first transaction descriptor in the pending queue,
423 - This function can be called in an interrupt context
425 - ``device_tx_status``
427 - Should report the bytes left to go over on the given channel
429 - Should only care about the transaction descriptor passed as
432 - The tx_state argument might be NULL
434 - Should use dma_set_residue to report it
436 - In the case of a cyclic transfer, it should only take into
439 - Should return DMA_OUT_OF_ORDER if the device does not support in order
442 - This function can be called in an interrupt context.
444 - device_config
446 - Reconfigures the channel with the configuration given as argument
448 - This command should NOT perform synchronously, or on any
451 - In this case, the function will receive a ``dma_slave_config``
455 - Even though that structure contains a direction field, this
459 - This call is mandatory for slave operations only. This should NOT be
461 If a driver support both, it should use this call for slave
464 - device_pause
466 - Pauses a transfer on the channel
468 - This command should operate synchronously on the channel,
471 - device_resume
473 - Resumes a transfer on the channel
475 - This command should operate synchronously on the channel,
478 - device_terminate_all
480 - Aborts all the pending and ongoing transfers on the channel
482 - For aborted transfers the complete callback should not be called
484 - Can be called from atomic context or from within a complete
488 - Termination may be asynchronous. The driver does not have to
492 - device_synchronize
494 - Must synchronize the termination of a channel to the current
497 - Must make sure that memory for previously submitted
500 - Must make sure that all complete callbacks for previously
504 - May sleep.
515 - Should be called at the end of an async TX transfer, and can be
516 ignored in the slave transfers case.
518 - Makes sure that dependent operations are run before marking it
523 - it's a DMA transaction ID that will increment over time.
525 - Not really relevant any more since the introduction of ``virt-dma``
530 - If clear, the descriptor cannot be reused by provider until the
534 - This can be acked by invoking async_tx_ack()
536 - If set, does not mean descriptor can be reused
540 - If set, the descriptor can be reused after being completed. It should
543 - The descriptor should be prepared for reuse by invoking
546 - ``dmaengine_desc_set_reuse()`` will succeed only when channel support
549 - As a consequence, if a device driver wants to skip the
554 - Descriptor can be freed in few ways
556 - Clearing DMA_CTRL_REUSE by invoking
559 - Explicitly invoking ``dmaengine_desc_free()``, this can succeed only
562 - Terminating the channel
564 - DMA_PREP_CMD
566 - If set, the client driver tells DMA controller that passed data in DMA
569 - Interpretation of command data is DMA controller specific. It can be
574 - DMA_PREP_REPEAT
576 - If set, the transfer will be automatically repeated when it ends until a
582 - This flag is only supported if the channel reports the DMA_REPEAT
585 - DMA_PREP_LOAD_EOT
587 - If set, the transfer will replace the transfer currently being executed at
590 - This is the default behaviour for non-repeated transfers, specifying
591 DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference.
593 - When using repeated transfers, DMA clients will usually need to set the
599 - This flag is only supported if the channel reports the DMA_LOAD_EOT
610 This is a rather inefficient design though, because the inter-transfer
623 - Burst: A number of consecutive read or write operations that
626 - Chunk: A contiguous collection of bursts
628 - Transfer: A collection of chunks (be it contiguous or not)