/linux/drivers/media/platform/amphion/ |
H A D | vpu_color.c | 79 u32 vpu_color_cvrt_transfers_v2i(u32 transfers) in vpu_color_cvrt_transfers_v2i() argument 81 return vpu_helper_find_in_array_u8(colortransfers, ARRAY_SIZE(colortransfers), transfers); in vpu_color_cvrt_transfers_v2i() 84 u32 vpu_color_cvrt_transfers_i2v(u32 transfers) in vpu_color_cvrt_transfers_i2v() argument 86 return transfers < ARRAY_SIZE(colortransfers) ? colortransfers[transfers] : 0; in vpu_color_cvrt_transfers_i2v() 117 int vpu_color_check_transfers(u32 transfers) in vpu_color_check_transfers() argument 119 return vpu_color_cvrt_transfers_v2i(transfers) ? 0 : -EINVAL; in vpu_color_check_transfers() 145 u32 transfers; in vpu_color_get_default() local 151 transfers = V4L2_XFER_FUNC_709; in vpu_color_get_default() 157 transfers = V4L2_XFER_FUNC_709; in vpu_color_get_default() 161 transfers = V4L2_XFER_FUNC_SMPTE240M; in vpu_color_get_default() [all …]
|
/linux/Documentation/driver-api/dmaengine/ |
H A D | provider.rst | 11 They have a given number of channels to use for the DMA transfers, and 41 really efficient, you'll get several bigger transfers. This is done 44 transfer into smaller sub-transfers. 46 Our theoretical DMA controller would then only be able to do transfers 48 transfers we usually have are not, and want to copy data from 52 DMAEngine, at least for mem2dev transfers, require support for 80 memory-to-device (mem2dev) kind of transfers. Most devices often 81 support other kind of transfers or memory operations that dmaengine 91 Over time, the need for memory to device transfers arose, and 125 (i.e. excluding mem2mem transfers) [all …]
|
H A D | pxa_dma.rst | 8 a) Transfers hot queuing 19 b) All transfers having asked for confirmation should be signaled 61 Transfers a single u32 to a well known dma coherent memory to leave 70 c) Transfers hot-chaining 109 d) Transfers completion updater 115 This will speed up residue calculation, for large transfers such as video 120 e) Transfers completion, irq and tasklet 129 - calling all the transfer callbacks of finished transfers, based on 138 transfers will be scanned for all of their descriptors against the 144 - there are not "acked" transfers (tx0)
|
/linux/drivers/spi/ |
H A D | spi-loopback-test.c | 25 /* flag to only simulate transfers */ 94 .transfers = { 108 .transfers = { 121 .transfers = { 133 .transfers = { 140 .description = "two tx-transfers - alter both", 146 .transfers = { 157 .description = "two tx-transfers - alter first", 163 .transfers = { 174 .description = "two tx-transfers - alter second", [all …]
|
H A D | spi-test.h | 41 * @transfers: array of @spi_transfers that are part of the 43 * @transfer_count: number of transfers 63 * @iterate_transfer_mask: the bitmask of transfers to which the iterations 75 struct spi_transfer transfers[SPI_TEST_MAX_TRANSFERS]; member
|
/linux/tools/usb/ |
H A D | hcd-tests.sh | 11 # - loop: needs firmware that will buffer N transfers 38 # set up to use interrupt transfers by 'usbtest' module options 126 echo "test 1: $COUNT transfers, same size" 128 echo "test 3: $COUNT transfers, variable/short size" 132 echo "test 17: $COUNT transfers, unaligned DMA map by core" 135 echo "test 19: $COUNT transfers, unaligned DMA map by usb_alloc_coherent" 166 echo "test 15: $COUNT transfers, same size" 175 echo "test 22: $COUNT transfers, non aligned" 187 echo "test 2: $COUNT transfers, same size" 189 echo "test 4: $COUNT transfers, variable size" [all …]
|
/linux/Documentation/usb/ |
H A D | ehci.rst | 59 and interrupt transfers, including requests to USB 1.1 devices through 67 transfers can't share much code with the code for high speed ISO transfers, 74 Transfers of all types can be queued. This means that control transfers 76 ones from another driver, and that interrupt transfers can use periods 88 transactions (interrupt and isochronous transfers). These place some 125 and bulk transfers. Shows each active qh and the qtds 130 and isochronous transfers. Doesn't show qtds. 140 can't, such as "high bandwidth" periodic (interrupt or ISO) transfers. 142 periodic transfers) use different encodings when operating at high speed. 160 Bulk transfers are most often used where throughput is an issue. It's [all …]
|
H A D | ohci.rst | 22 - interrupt transfers can be larger, and can be queued 27 The "ohci-hcd" driver handles all USB 1.1 transfer types. Transfers of all 29 transfers. Previously, using periods of one frame would risk data loss due 30 to overhead in IRQ processing. When interrupt transfers are queued, those 31 risks can be minimized by making sure the hardware always has transfers to
|
/linux/drivers/usb/gadget/udc/ |
H A D | Kconfig | 136 zero (for control transfers). 157 supports both full and high speed USB 2.0 data transfers. 169 that supports both full and high speed USB 2.0 data transfers. 194 that supports super, high, and full speed USB 3.0 data transfers. 219 control transfers). 263 supports both full and high speed USB 2.0 data transfers. 313 supports both full and high speed USB 2.0 data transfers. 316 (for control transfers) and several endpoints with dedicated 323 data transfers. 326 (for control transfers) and several endpoints with dedicated [all …]
|
/linux/Documentation/i2c/ |
H A D | i2c-topology.rst | 25 I2C transfers, and all adapters with a parent are part of an "i2c-mux" 49 select and/or deselect operations must use I2C transfers to complete 51 full transaction, unrelated I2C transfers may interleave the different 74 4. M1 (presumably) does some I2C transfers as part of its select. 75 These transfers are normal I2C transfers that locks the parent 114 number (one, in most cases) of I2C transfers. Unrelated I2C transfers 130 has to ensure that any and all I2C transfers through that parent 131 adapter during the transaction are unlocked I2C transfers (using e.g. 154 5. If M1 does any I2C transfers (on this root adapter) as part of 155 its select, those transfers must be unlocked I2C transfers so [all …]
|
/linux/Documentation/core-api/ |
H A D | dma-isa-lpc.rst | 7 This document describes how to do DMA transfers using the old ISA DMA 22 The second contains the routines specific to ISA DMA transfers. Since 34 (You usually need a special buffer for DMA transfers instead of 69 8-bit transfers and the upper four are for 16-bit transfers. 80 The ability to use 16-bit or 8-bit transfers is _not_ up to you as a 105 be 16-bit aligned for 16-bit transfers) and how many bytes to
|
/linux/Documentation/driver-api/usb/ |
H A D | URB.rst | 33 - Transfers for one URB can be canceled with :c:func:`usb_unlink_urb` 67 // (IN) buffer used for data transfers 78 // Only for PERIODIC transfers (ISO, INTERRUPT) 150 - Too many queued ISO transfers (``-EAGAIN``) 224 transferred. That's because USB transfers are packetized; it might take 239 How to do isochronous (ISO) transfers? 243 have to set ``urb->interval`` to say how often to make transfers; it's 249 For ISO transfers you also have to fill a :c:type:`usb_iso_packet_descriptor` 275 How to start interrupt (INT) transfers? 278 Interrupt transfers, like isochronous transfers, are periodic, and happen
|
/linux/include/linux/platform_data/ |
H A D | edma.h | 11 * Channel Triggers transfers, usually from a hardware event but 21 * Each PaRAM set describes a sequence of transfers, either for one large 23 * is driven only from a channel, which performs the transfers specified 24 * in its PaRAM slot until there are no more transfers. When that last 66 * This way, long transfers on the default queue started
|
H A D | dma-dw.h | 27 * @m_master: memory master for transfers on allocated channel 28 * @p_master: peripheral master for transfers on allocated channel 51 * @multi_block: Multi block transfers supported by hardware per channel.
|
/linux/Documentation/devicetree/bindings/dma/stm32/ |
H A D | st,stm32-dma.yaml | 20 0x0: no address increment between transfers 21 0x1: increment address between transfers 23 0x0: no address increment between transfers 24 0x1: increment address between transfers 49 managing transfers for STM32 USART/UART.
|
/linux/tools/perf/pmu-events/arch/x86/tigerlake/ |
H A D | uncore-memory.json | 3 …ontroller to DRAM (sum of all channels). All requests result in 64 byte data transfers from DRAM.", 21 …ontroller to DRAM (sum of all channels). All requests result in 64 byte data transfers from DRAM.", 30 …ontroller to DRAM (sum of all channels). All requests result in 64 byte data transfers from DRAM.", 48 …ontroller to DRAM (sum of all channels). All requests result in 64 byte data transfers from DRAM.",
|
/linux/drivers/usb/c67x00/ |
H A D | c67x00-hcd.h | 22 * These can be tuned for specific use cases, e.g. if isochronous transfers 25 * If bulk transfers are important, the MAX_FRAME_BW can be increased, 33 * isochronous transfers are scheduled), in order to optimize the throughput 47 * Periodic transfers may only use 90% of the full frame, but as 49 * use the full usable time for periodic transfers.
|
/linux/Documentation/ABI/testing/ |
H A D | sysfs-bus-mdio | 10 What: /sys/bus/mdio_bus/devices/.../statistics/transfers 11 What: /sys/class/mdio_bus/.../transfers 16 Total number of transfers for this MDIO bus. 48 Total number of transfers for this MDIO bus address.
|
/linux/include/linux/spi/ |
H A D | spi.h | 44 * struct spi_statistics - statistics for spi transfers 49 * @transfers: number of spi_transfers handled 67 * number of transfers that have been split because of 74 u64_stats_t transfers; member 139 * @bits_per_word: Data transfers involve one or more words; word sizes 428 * It's always safe to call this unless transfers are pending on 470 * message while queuing transfers that arrive in the meantime. When the 540 * for spi_sync transfers. 588 /* Bitmask of supported bits_per_word for transfers */ 645 * IMPORTANT: this may be called when transfers to another [all …]
|
/linux/include/uapi/linux/ |
H A D | parport.h | 86 * other than to make parport_read/write use address transfers. */ 93 #define PARPORT_EPP_FAST_32 PARPORT_EPP_FAST /* 32-bit EPP transfers */ 94 #define PARPORT_EPP_FAST_16 (1<<2) /* 16-bit EPP transfers */ 95 #define PARPORT_EPP_FAST_8 (1<<3) /* 8-bit EPP transfers */
|
/linux/drivers/dma/ |
H A D | Kconfig | 10 DMA engines can do asynchronous data transfers without 400 This DMA controller transfers data from memory to peripheral fifo. 428 implementation that performs complex data transfers with 564 transfers. 623 This DMA controller transfers data from memory to peripheral FIFO 635 This DMA controller transfers data from memory to peripheral fifo 647 audio processing engine (APE). This DMA controller transfers 701 Memory Mapped (S2MM) for the data transfers. 721 and the DMA subsystem. These direct memory transfers can be both in 722 the Host to Card (H2C) and Card to Host (C2H) transfers.
|
/linux/Documentation/networking/ |
H A D | j1939.rst | 92 - These are automatically handled as J1939 Transport Protocol (TP) transfers. 96 - TP transfers can be unicast or broadcast. 106 - These are handled as ISO 11783 Extended Transport Protocol (ETP) transfers. 108 - ETP transfers are used for larger payloads and are split into multiple CAN 111 - **ETP transfers (unicast):** Require a receiver on the other side to 114 - ETP transfers cannot be broadcast like TP transfers, and always require a 123 monitor this value and handle partial transfers. 136 - **Simple transfers (<= 8 bytes):** Do not require a receiver on the other 145 TP transfers. ETP cannot be broadcast and always needs a receiving client. 646 message transfers and errors. [all …]
|
/linux/tools/perf/pmu-events/arch/x86/amdzen1/ |
H A D | core.json | 23 … This includes those for which prediction is not attempted (far control transfers, exceptions and … 40 "BriefDescription": "Retired Far Control Transfers.", 41 …far control transfers retired including far call/jump/return, IRET, SYSCALL and SYSRET, plus excep…
|
/linux/drivers/rapidio/ |
H A D | Kconfig | 35 than Maintenance transfers. 44 transfers to/from target RIO devices. RapidIO uses NREAD and 47 capable to perform data transfers to/from RapidIO.
|
/linux/tools/perf/pmu-events/arch/x86/amdzen2/ |
H A D | core.json | 23 … This includes those for which prediction is not attempted (far control transfers, exceptions and … 40 "BriefDescription": "Retired Far Control Transfers.", 41 …far control transfers retired including far call/jump/return, IRET, SYSCALL and SYSRET, plus excep…
|