Searched refs:operations (Results 1 – 25 of 527) sorted by relevance
12345678910>>...22
| /Linux-v4.19/Documentation/ |
| D | atomic_bitops.txt | 5 While our bitmap_{}() functions are non-atomic, we have a number of operations
12 The single bit operations are:
18 RMW atomic operations without return value:
23 RMW atomic operations with return value:
33 All RMW atomic operations have a '__' prefixed variant which is non-atomic.
47 The test_and_{}_bit() operations return the original value of the bit.
55 - non-RMW operations are unordered;
57 - RMW operations that have no return value are unordered;
59 - RMW operations that have a return value are fully ordered.
61 - RMW operations that are conditional are unordered on FAILURE,
[all …]
|
| D | atomic_t.txt | 5 RMW operations between CPUs (atomic operations on MMIO are not supported and
20 RMW atomic operations:
119 - plain operations without return value: atomic_{}()
121 - operations which return the modified value: atomic_{}_return()
123 these are limited to the arithmetic operations because those are
127 - operations which return the original value: atomic_fetch_{}()
129 - swap operations: xchg(), cmpxchg() and try_cmpxchg()
131 - misc; the special purpose operations that are commonly used and would,
136 All these operations are SMP atomic; that is, the operations (for a single
146 - non-RMW operations are unordered;
[all …]
|
| D | this_cpu_ops.txt | 2 this_cpu operations
8 this_cpu operations are a way of optimizing access to per cpu
14 this_cpu operations add a per cpu variable offset to the processor
24 Read-modify-write operations are of particular interest. Frequently
39 (remote write operations) of local RMW operations via this_cpu_*.
41 The main use of the this_cpu operations has been to optimize counter
42 operations.
44 The following this_cpu() operations with implied preemption protection
45 are defined. These operations can be used without worrying about
65 Inner working of this_cpu operations
[all …]
|
| /Linux-v4.19/Documentation/virtual/ |
| D | paravirt_ops.txt | 8 hypervisors. It allows each hypervisor to override critical operations and
12 pv_ops provides a set of function pointers which represent operations
15 time by enabling binary patching of the low-ops critical operations
18 pv_ops operations are classified into three categories:
21 These operations correspond to high level functionality where it is
25 Usually these operations correspond to low level critical instructions. They
|
| /Linux-v4.19/Documentation/arm/ |
| D | firmware.txt | 1 Interface for registering and calling firmware-specific operations for ARM.
8 operations and call them when needed.
10 Firmware operations can be specified by filling in a struct firmware_ops
19 There is a default, empty set of operations provided, so there is no need to
20 set anything if platform does not require firmware operations.
31 Example of registering firmware operations:
50 /* other operations not available on platformX */
|
| /Linux-v4.19/Documentation/core-api/ |
| D | local_ops.rst | 11 This document explains the purpose of the local atomic operations, how
18 Note that ``local_t`` based operations are not recommended for general
19 kernel use. Please use the ``this_cpu`` operations instead unless there is
21 replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the
26 Purpose of local atomic operations
29 Local atomic operations are meant to provide fast and highly reentrant per CPU
30 counters. They minimize the performance cost of standard atomic operations by
39 Local atomic operations only guarantee variable modification atomicity wrt the
50 It can be done by slightly modifying the standard atomic operations: only
63 Rules to follow when using local atomic operations
[all …]
|
| D | atomic_ops.rst | 31 The first operations to implement for atomic_t's are the initializers and
41 The initializer is atomic in that the return values of the atomic operations
62 The setting is atomic in that the return values of the atomic operations by
74 values initialized or modified with the interface operations if a proper
77 interface operations. atomic_read does not guarantee that the runtime
180 locks, or atomic operations if variable a can change at runtime!
214 the operation. It must be done such that all memory operations before
273 with the given old and new values. Like all atomic_xxx operations,
275 other accesses of \*v are performed through atomic_xxx operations.
308 read-modify-write atomic operations.
[all …]
|
| /Linux-v4.19/Documentation/crypto/ |
| D | async-tx-api.txt | 9 3.2 Supported operations
31 the API will fit the chain of operations to the available offload
47 operations to be submitted, like xor->copy->xor in the raid5 case. The
59 3.2 Supported operations:
79 operations complete. When an application needs to submit a chain of
80 operations it must guarantee that the descriptor is not automatically recycled
85 1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted
92 async_<operation> call. Offload engine drivers batch operations to
95 automatically issues pending operations. An application can force this
105 chains and issuing pending operations.
[all …]
|
| /Linux-v4.19/Documentation/devicetree/bindings/dma/ |
| D | ste-dma40.txt | 60 bidirectional, i.e. the same for RX and TX operations:
113 51: memcpy TX (to be used by the DMA driver for memcpy operations)
118 56: memcpy (to be used by the DMA driver for memcpy operations)
119 57: memcpy (to be used by the DMA driver for memcpy operations)
120 58: memcpy (to be used by the DMA driver for memcpy operations)
121 59: memcpy (to be used by the DMA driver for memcpy operations)
122 60: memcpy (to be used by the DMA driver for memcpy operations)
|
| D | mv-xor.txt | 20 - dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
21 - dmacap,memset to indicate that the XOR channel is capable of memset operations
22 - dmacap,xor to indicate that the XOR channel is capable of xor operations
|
| /Linux-v4.19/Documentation/networking/ |
| D | nfc.txt | 20 responsible for providing an interface to control operations and low-level
23 The control operations are available to userspace via generic netlink.
34 | data exchange | operations
69 The userspace interface is divided in control operations and low-level data
74 Generic netlink is used to implement the interface to the control operations.
75 The operations are composed by commands and events, all listed below:
98 All polling operations requested through one netlink socket are stopped when
|
| /Linux-v4.19/Documentation/ABI/testing/ |
| D | debugfs-pfo-nx-crypto | 33 - The total number of AES operations submitted to the hardware.
39 - The total number of SHA-256 operations submitted to the hardware.
45 - The total number of SHA-512 operations submitted to the hardware.
|
| /Linux-v4.19/Documentation/arm/VFP/ |
| D | release-notes.txt | 17 The operations which have been tested with this package are:
39 Other operations which have been tested by basic assembly-only tests
49 The combination operations have not been tested:
|
| /Linux-v4.19/Documentation/driver-api/ |
| D | clk.rst | 17 gating, rate adjustment, muxing or other operations. This framework is
25 drivers/clk/clk.c. Finally there is struct clk_ops, whose operations
67 the operations defined in clk-provider.h::
175 To take advantage of your data you'll need to support valid operations
271 .disable operations. Those operations are thus not allowed to sleep,
285 The prepare lock is a mutex and is held across calls to all other operations.
286 All those operations are allowed to sleep, and calls to the corresponding API
289 This effectively divides operations in two groups from a locking perspective.
291 Drivers don't need to manually protect resources shared between the operations
293 clocks or not. However, access to resources that are shared between operations
[all …]
|
| D | i2c.rst | 26 are functions to perform various I2C protocol operations; at this writing
32 Controllers that support I2C can also support most SMBus operations, but
35 operations, either using I2C primitives or by issuing SMBus commands to
36 i2c_adapter devices which don't support those I2C operations.
|
| /Linux-v4.19/Documentation/filesystems/caching/ |
| D | operations.txt | 24 FS-Cache has an asynchronous operations handling facility that it uses for its
25 data storage and retrieval routines. Its operations are represented by
30 and FS-Cache will create operations and pass them off to the appropriate cache
76 operations:
82 This is, for example, used in read operations for calling readpages() on
122 Furthermore, operations may be one of two types:
132 operations running at the same time.
162 The operation manager will defer operations on an object that is still
|
| /Linux-v4.19/Documentation/scsi/ |
| D | ufs.txt | 60 * Device manager: It handles device level operations and device
61 configuration operations. Device level operations mainly involve
62 device power management operations and commands to Interconnect
73 manager for device level operations. These device level operations
|
| /Linux-v4.19/net/rds/ |
| D | Kconfig | 14 This transport supports RDMA operations.
22 This transport does not support RDMA operations.
|
| /Linux-v4.19/Documentation/driver-api/soundwire/ |
| D | locking.rst | 6 following locks in order to avoid race conditions in Bus operations on
18 serialize each of the following operations(s) within SoundWire Bus instance.
22 - Prepare, Enable, Disable and De-prepare stream operations.
|
| D | stream.rst | 117 SoundWire Bus manages stream operations for each stream getting
118 rendered/captured on the SoundWire Bus. This section explains Bus operations
151 Below section explains the operations done by the Bus on Master(s) and
161 runtime is used as a reference for all the operations performed
169 After all above operations are successful, stream state is set to
194 After all above operations are successful, stream state is set to
240 After all above operations are successful, stream state is set to
269 After all above operations are successful, stream state is set to
296 After all above operations are successful, stream state is set to
320 After all above operations are successful, stream state is set to
[all …]
|
| /Linux-v4.19/Documentation/devicetree/bindings/powerpc/opal/ |
| D | sensor-groups.txt | 17 operations like clearing the min/max history of all
25 - ops : Array of opal-call numbers indicating available operations on
|
| /Linux-v4.19/Documentation/gpu/ |
| D | drm-mm.rst | 92 operations to userspace and a set of helper functions to drivers, and
93 let drivers implement hardware-specific operations with their own
99 principles. Buffer allocation and read and write operations, described
109 On a fundamental level, GEM involves several operations:
119 Device-specific operations, such as command execution, pinning, buffer
145 backs them in two distinct operations.
255 Because mapping operations are fairly heavyweight GEM favours
283 value and set the VMA operations to the :c:type:`struct drm_driver
290 with a pointer to VM operations.
292 The VM operations is a :c:type:`struct vm_operations_struct <vm_operations_struct>`
[all …]
|
| /Linux-v4.19/arch/unicore32/mm/ |
| D | Kconfig | 35 Say Y here to disable the data cache line operations.
41 Say Y here to disable the TLB single entry operations.
|
| /Linux-v4.19/Documentation/filesystems/ |
| D | spufs.txt | 35 the operations supported on regular file systems. This list details the
36 supported operations and the deviations from the behaviour in the
41 All files support the access(2) and stat(2) family of operations, but
47 possible operations, e.g. read access on the wbox file.
55 data in the address space of the SPU. The possible operations on an
74 operations on an open mbox file are:
88 operations on an open ibox file are:
111 operations on an open wbox file are: write(2) If a count smaller than
135 operations on an open *box_stat file are:
173 The possible operations on an open npc, decr, decr_status,
[all …]
|
| /Linux-v4.19/Documentation/rapidio/ |
| D | mport_cdev.txt | 20 This driver (MPORT_CDEV) provides access to basic RapidIO subsystem operations
21 for user-space applications. Most of RapidIO operations are supported through
29 following RapidIO bus and subsystem operations:
34 This operations are defined as RapidIO Maintenance reads/writes in RIO spec.
|
12345678910>>...22
