Searched full:transfer (Results 1 – 25 of 236) sorted by relevance
12345678910
| /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 | 91 setting the DMA_PREP_REPEAT transfer flag.
93 A non-NULL return of this transfer API represents a "descriptor" for
178 after their transfer completion callback has run for the descriptor.
179 If no completion callback has been defined for the transfer, then the
181 In other words: if the aim is to read back metadata after the transfer is
209 3. submit the transfer
216 3. submit the transfer
217 4. when the transfer is completed, the metadata should be available in the
230 5. submit the transfer
235 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/dma/ |
| 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 | 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.
|
| D | fsl-imx-sdma.txt | 27 The second cell of dma phandle specifies the peripheral type of DMA transfer.
30 ID transfer type
58 The third cell specifies the transfer priority as below.
60 ID transfer priority
|
| /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
49 The transfer function defined for SMPTE 170M is the same as the one
60 Inverse Transfer function:
96 general. The default transfer function is ``V4L2_XFER_FUNC_709``. The
129 Transfer function. Normally L is in the range [0…1], but for the
140 Inverse Transfer function:
217 and computer graphics. The default transfer function is
256 Transfer function. Note that negative values for L are only used by the
267 Inverse Transfer function:
299 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/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/spi/ |
| D | spidev.rst | 90 settings for data transfer parameters:
94 return (RD) or assign (WR) the SPI transfer mode. Use the constants
103 which will return (RD) or assign (WR) the full SPI transfer mode,
109 transfer SPI words. Zero indicates MSB-first; other values indicate
117 each SPI transfer word. The value zero signifies eight bits.
121 u32 which will return (RD) or assign (WR) the maximum SPI transfer
138 - There's a limit on the number of bytes each I/O request can transfer
142 - Because SPI has no low-level transfer acknowledgement, you usually
151 transfer.) The model is the same as that used in the kernel spi_sync()
160 and bitrate for each transfer segment.)
[all …]
|
| D | spi-summary.rst | 409 buffer for each transfer direction, supporting full duplex
417 + whether the chipselect becomes inactive after a transfer and
422 transfer in that atomic group, and potentially saving costs
453 transfer mode, wordsize, or clock rate. This is done with spi_setup(),
557 driver to prepare the transfer hardware by issuing this call.
566 The subsystem calls the driver to transfer a single message while
572 …r->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *transfer)``
573 The subsystem calls the driver to transfer a single transfer while
575 finished with this transfer, it must call
577 transfer. This may sleep. Note: transfer_one and transfer_one_message
[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
84 A transfer's actual_length may be positive even when an error has been
98 0 Transfer completed successfully
129 to indicate timeout expired before the transfer
137 ``-ECOMM`` During an IN transfer, the host controller
141 ``-ENOSR`` During an OUT transfer, the host controller
[all …]
|
| D | URB.rst | 41 You can fill that queue, so that the USB hardware can still transfer
44 of data to (or from) devices when using periodic transfer modes.
100 The parameter isoframes specifies the number of isochronous transfer frames
121 the pipe (usual format from usb.h), the transfer buffer, the desired transfer
225 sixteen packets to transfer your 1KByte buffer, and ten of them might
242 Besides the fields present on a bulk transfer, for ISO, you also
247 most ISO transfer fields.
260 status contains the resulting status for the ISO transfer for this frame.
262 audio synchronisation/adaptive transfer rates). You can also use the length
281 You can use the :c:func:`usb_fill_int_urb` macro to fill INT transfer fields.
|
| /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/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/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/spi/ |
| D | spi-xilinx.txt | 12 - xlnx,num-transfer-bits : Number of bits per transfer. This will be 8 if not specified
21 xlnx,num-transfer-bits = <32>;
|
| /Documentation/devicetree/bindings/sound/ |
| D | sprd-mcdt.txt | 1 Spreadtrum Multi-Channel Data Transfer Binding
3 The Multi-channel data transfer controller is used for sound stream
|
| /Documentation/devicetree/bindings/i2c/ |
| D | nvidia,tegra20-i2c.txt | 21 Continue Transfer Support. This feature helps to implement M_NO_START
22 as per I2C core API transfer flags. Driver of I2C controller is
23 compatible with "nvidia,tegra30-i2c" to enable the continue transfer
25 continue transfer support.
32 - Tegra30/Tegra20 I2C controller has enabled per packet transfer by
|
| /Documentation/driver-api/i3c/ |
| D | protocol.rst | 112 I3C transfer types
116 exposed by I2C devices), I2C has only one transfer type.
118 I3C defines 3 different classes of transfer in addition to I2C transfers which
148 device specific and does not require high transfer speed.
150 It is the equivalent of I2C transfers but in the I3C world. Each transfer is
154 The only difference with I2C is that the transfer is much faster (typical clock
161 high transfer speed.
|
12345678910