Searched full:transfer (Results 1 – 25 of 284) sorted by relevance
12345678910>>...12
| /Documentation/driver-api/dmaengine/ |
| D | provider.rst | 21 will want to start a transfer, it will assert a DMA request (DRQ) by
25 parameter: the transfer size. At each clock cycle, it would transfer a
26 byte of data from one buffer to another, until the transfer size has
31 cycle. For example, we may want to transfer as much data as the
36 parameter called the transfer width.
44 transfer into smaller sub-transfers.
59 transfer, and whenever the transfer is started, the controller will go
73 transfer width and the transfer size.
118 should contain a bitmask of the supported source transfer width
121 should contain a bitmask of the supported destination transfer width
[all …]
|
| D | pxa_dma.rst | 9 A driver submitting a transfer and issuing it should be granted the transfer
11 This implies that the queuing doesn't wait for the previous transfer end,
13 triggered by the end of the transfer.
14 A transfer which is submitted and issued on a phy doesn't wait for a phy to
17 a new transfer.
20 Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call.
27 multimedia case, such as video capture, if a transfer is submitted and then
28 a check of the DMA channel reports a "stopped channel", the transfer should
44 assigned on the fly when the transfer is issued.
46 b) Transfer anatomy for a scatter-gather transfer
[all …]
|
| D | client.rst | 95 setting the DMA_PREP_REPEAT transfer flag.
97 A non-NULL return of this transfer API represents a "descriptor" for
189 after their transfer completion callback has run for the descriptor.
190 If no completion callback has been defined for the transfer, then the
192 In other words: if the aim is to read back metadata after the transfer is
220 3. submit the transfer
227 3. submit the transfer
228 4. when the transfer is completed, the metadata should be available in the
241 5. submit the transfer
246 2. submit the transfer
[all …]
|
| /Documentation/mhi/ |
| D | mhi.rst | 58 Transfer rings: Used by the host to schedule work items for a channel. The
59 transfer rings are organized as a circular queue of Transfer Descriptors (TD).
81 Two unidirectional channels with their associated transfer rings form a
85 transfer ring.
87 Transfer rings
91 Transfer Descriptors (TD). TDs are managed through transfer rings, which are
93 memory. TDs consist of one or more ring elements (or transfer blocks)::
101 Below is the basic usage of transfer rings:
103 * Host allocates memory for transfer ring.
118 data transfer completion status, command completion status, and state changes
[all …]
|
| D | topology.rst | 16 It is however not involved in the actual data transfer as the data transfer
57 * Prepares the device for transfer by calling mhi_prepare_for_transfer.
58 * Initiates data transfer by calling mhi_queue_transfer.
59 * Once the data transfer is finished, calls mhi_unprepare_from_transfer to
60 end data transfer.
|
| /Documentation/devicetree/bindings/mailbox/ |
| D | arm,mhuv2.yaml | 33 - Data-transfer: Each transfer is made of one or more words, using one or more
36 - Doorbell: Each transfer is made up of single bit flag, using any one of the
96 The first field of a tuple signifies the transfer protocol, 0 is reserved
97 for doorbell protocol, and 1 is reserved for data-transfer protocol.
103 windows that implement the doorbell protocol. For data-transfer protocol,
105 the data-transfer protocol.
120 7 windows (separately) used in data-transfer protocol.
135 doorbell, or data-transfer protocol, and the second argument (only
144 mboxes = <&mhu 2 0>; // Channel Window Group 2, data transfer protocol with 1 window.
145 mboxes = <&mhu 3 0>; // Channel Window Group 3, data transfer protocol with 5 windows.
[all …]
|
| D | arm,mhuv3.yaml | 29 - Optionally receive acknowledgment of a Transfer from the Receiver
49 Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
50 Sender to Receiver. The Transfer indicates that an event has occurred.
56 Transfers at once using a single DBCH, so long as each Transfer uses
69 knowing if, or when, the Receiver will act on the Transfer.
86 previous Transfer to be acknowledged by the Receiver, as long as the
87 FIFO has room for the Transfer.
150 description: MBX Doorbell Channel <N> Transfer interrupt
152 description: MBX FastChannel <N> Transfer interrupt
154 description: MBX FastChannel <N> Group Transfer interrupt
[all …]
|
| /Documentation/devicetree/bindings/dma/stm32/ |
| D | st,stm32-mdma.yaml | 24 0x2: Source address pointer is incremented after each data transfer
25 0x3: Source address pointer is decremented after each data transfer
28 0x2: Destination address pointer is incremented after each data transfer
29 0x3: Destination address pointer is decremented after each data transfer
40 -bit 25-18: The number of bytes to be transferred in a single transfer
43 0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
44 0x1: Each MDMA request triggers a block transfer (max 64K bytes)
45 0x2: Each MDMA request triggers a repeated block transfer
46 0x3: Each MDMA request triggers a linked list transfer
|
| D | st,stm32-dma3.yaml | 72 The third cell is a 32-bit mask specifying the DMA transfer requirements:
77 0x0: port 0 is allocated to the source transfer
78 0x1: port 1 is allocated to the source transfer
83 0x0: port 0 is allocated to the destination transfer
84 0x1: port 1 is allocated to the destination transfer
91 -bit 12-13: The transfer complete event mode
92 0x0: at block level, transfer complete event is generated at the end
94 0x2: at LLI level, the transfer complete event is generated at the end
95 of the LLI transfer
97 0x3: at channel level, the transfer complete event is generated at the
|
| /Documentation/userspace-api/media/v4l/ |
| D | colorspaces-defs.rst | 9 which defines the chromaticities, the default transfer function, the
11 is the transfer function identifier (enum
13 transfer functions. The third is the Y'CbCr encoding identifier (enum
80 .. flat-table:: V4L2 Transfer Function
87 - Use the default transfer function as defined by the colorspace.
89 - Use the Rec. 709 transfer function.
91 - Use the sRGB transfer function.
93 - Use the opRGB transfer function.
95 - Use the SMPTE 240M transfer function.
97 - Do not use a transfer function (i.e. use linear RGB values).
[all …]
|
| D | colorspaces-details.rst | 14 PAL and by SDTV in general. The default transfer function is
45 The transfer function defined for SMPTE 170M is the same as the one
56 Inverse Transfer function:
92 general. The default transfer function is ``V4L2_XFER_FUNC_709``. The
121 Transfer function. Normally L is in the range [0…1], but for the
132 Inverse Transfer function:
209 and computer graphics. The default transfer function is
244 Transfer function. Note that negative values for L are only used by the
255 Inverse Transfer function:
287 graphics that use the opRGB colorspace. The default transfer function is
[all …]
|
| /Documentation/driver-api/soundwire/ |
| D | locking.rst | 29 SoundWire message transfer lock. This mutex is part of
38 Message transfer.
40 1. For every message transfer
44 b. Transfer message (Read/Write) to Slave1 or broadcast message on
60 | | b. Transfer message
74 2. For every message transfer in Prepare operation
78 b. Transfer message (Read/Write) to Slave1 or broadcast message on
99 | | b. Transfer message
|
| /Documentation/arch/arm/stm32/ |
| D | stm32-dma-mdma-chaining.rst | 30 without the ability to generate convenient burst transfer ensuring the best
54 the STM32 DMA transfer.
58 channel is null. The channel transfer complete of the last node is the end of
59 transfer, unless first and last nodes are linked to each other, in such a
60 case, the linked-list loops on to create a circular MDMA transfer.
64 resources and bus congestion. Transfer Complete signal of STM32 DMA channel
65 can triggers STM32 MDMA transfer. STM32 MDMA can clear the request generated
73 | channels | channels | Transfer | request |
133 * the address of the STM32 DMA register to clear the Transfer Complete
135 * the mask of the Transfer Complete interrupt flag of the STM32 DMA channel.
[all …]
|
| /Documentation/core-api/ |
| D | dma-isa-lpc.rst | 38 Also the transfer block may not cross page boundaries (which are 64
84 Transfer data
87 Now for the good stuff, the actual DMA transfer. :)
101 transfer using set_dma_mode(). Currently you have the options
104 Set the address from where the transfer should start (this needs to
106 transfer. Note that it's _bytes_. The DMA routines will do all the
112 Once the DMA transfer is finished (or timed out) you should disable
140 printk(KERN_ERR "driver: Incomplete DMA transfer!"
149 suspended while a DMA transfer is in progress. Also, all DMA settings
|
| /Documentation/driver-api/mmc/ |
| D | mmc-async-req.rst | 13 transfer, the DMA preparation overhead would not affect the MMC performance.
35 in parallel with the transfer performance won't be affected.
67 with the previous transfer, since there is no previous request.
73 and finally prepare the second chunk and start the transfer.
78 /* start MMC transfer for the complete transfer size */
86 * the transfer is delayed, guesstimate max 4k as first chunk size.
96 * before this call, the transfer is delayed.
|
| /Documentation/networking/ |
| D | plip.rst | 83 mode as compared to IRQ mode as far as the data transfer speed is involved.
87 data transfer (the maximal time the PLIP driver would allow the other side
88 before announcing a timeout, when trying to handshake a transfer of some
116 PLIP uses several different data transfer methods. The first (and the
118 printer "null" cable to transfer data four bits at a time using
121 The second data transfer method relies on both machines having
126 Parallel Transfer Mode 0 Cable
129 The cable for the first transfer mode is a standard
159 Parallel Transfer Mode 1
162 The second data transfer method relies on both machines having
[all …]
|
| /Documentation/driver-api/usb/ |
| D | error-codes.rst | 13 behave the same except for transfer speed dependent behaviors and the
42 ``-EINVAL`` a) Invalid transfer type specified (or not supported)
43 b) Invalid or unsupported periodic transfer interval
44 c) ISO: attempted to change transfer interval
61 (c) requested data transfer length is invalid: negative
87 A transfer's actual_length may be positive even when an error has been
101 0 Transfer completed successfully
132 to indicate timeout expired before the transfer
140 ``-ECOMM`` During an IN transfer, the host controller
144 ``-ENOSR`` During an OUT transfer, the host controller
[all …]
|
| /Documentation/devicetree/bindings/iio/pressure/ |
| D | honeywell,mprls0025pa.yaml | 20 differ in the pressure range, unit and transfer function.
23 as the transfer function.
31 The transfer function defines the ranges of numerical values delivered by the
60 honeywell,transfer-function:
62 Transfer function which defines the range of valid values delivered by the
98 - honeywell,transfer-function
136 honeywell,transfer-function = <1>;
154 honeywell,transfer-function = <1>;
|
| D | honeywell,hsc030pa.yaml | 18 identical programming model but differ in pressure range, unit and transfer
22 as the transfer function. Pressure range can either be provided via
26 The transfer function defines the ranges of raw conversion values delivered
47 honeywell,transfer-function:
49 Transfer function which defines the range of valid values delivered by
99 - honeywell,transfer-function
126 honeywell,transfer-function = <0>;
139 honeywell,transfer-function = <0>;
|
| /Documentation/devicetree/bindings/misc/ |
| D | atmel-ssc.txt | 5 - atmel,at91rm9200-ssc: support pdc transfer
6 - atmel,at91sam9g45-ssc: support dma transfer
31 - PDC transfer:
40 - DMA transfer:
|
| /Documentation/spi/ |
| D | spidev.rst | 118 settings for data transfer parameters:
122 return (RD) or assign (WR) the SPI transfer mode. Use the constants
131 which will return (RD) or assign (WR) the full SPI transfer mode,
137 transfer SPI words. Zero indicates MSB-first; other values indicate
145 each SPI transfer word. The value zero signifies eight bits.
149 u32 which will return (RD) or assign (WR) the maximum SPI transfer
166 - There's a limit on the number of bytes each I/O request can transfer
170 - Because SPI has no low-level transfer acknowledgement, you usually
179 transfer.) The model is the same as that used in the kernel spi_sync()
188 and bitrate for each transfer segment.)
[all …]
|
| /Documentation/usb/ |
| D | ehci.rst | 9 compatible with the USB 1.1 standard. It defines three transfer speeds:
24 high speed "split transactions" that don't waste transfer bandwidth.
55 Transfer Types
62 High Speed Isochronous (ISO) transfer support is also functional, but
65 Full Speed Isochronous transfer support, through transaction translators,
155 them. The 480 Mbit/sec "raw transfer rate" is obeyed by all devices,
166 hardware and device driver software allow it. Periodic transfer modes
168 approach the quoted 480 MBit/sec transfer rate.
174 20 MByte/sec transfer rates. This is of course subject to change;
178 at around 28 MByte/sec aggregate transfer rate. While this is clearly
[all …]
|
| /Documentation/devicetree/bindings/dma/ |
| D | milbeaut-m10v-hdmac.txt | 3 Milbeaut AHB DMA controller has transfer capability below.
4 - device to memory transfer
5 - memory to device transfer
|
| D | socionext,uniphier-xdmac.yaml | 11 memory-to-memory or peripheral-to-memory data transfer capable of supporting
35 2. Transfer request factor number, If no transfer factor, use 0.
|
| /Documentation/devicetree/bindings/spi/ |
| D | spi-xilinx.yaml | 33 xlnx,num-transfer-bits:
34 description: Number of bits per transfer. This will be 8 if not specified.
53 xlnx,num-transfer-bits = <32>;
|
12345678910>>...12