Searched full:side (Results 1 – 25 of 453) sorted by relevance
12345678910>>...19
| /Documentation/devicetree/bindings/interrupt-controller/ |
| D | fsl,mu-msi.yaml | 16 for one processor (A side) to signal the other processor (B side) using
20 different clocks (from each side of the different peripheral buses).
21 Therefore, the MU must synchronize the accesses from one side to the
23 registers (Processor A-side, Processor B-side).
40 - description: a side register base address
41 - description: b side register base address
45 - const: processor-a-side
46 - const: processor-b-side
49 description: a side interrupt number.
57 - description: a side power domain
[all …]
|
| /Documentation/locking/ |
| D | seqlock.rst | 15 read side critical section is even and the same sequence count value is
17 be copied out inside the read side critical section. If the sequence
24 the end of the write side critical section the sequence count becomes
27 A sequence counter write side critical section must never be preempted
28 or interrupted by read side sections. Otherwise the reader will spin for
43 multiple writers. Write side critical sections must thus be serialized
48 write side section. If the read section can be invoked from hardirq or
76 /* ... [[write-side critical section]] ... */
85 /* ... [[read-side critical section]] ... */
95 As discussed at :ref:`seqcount_t`, sequence count write side critical
[all …]
|
| /Documentation/usb/ |
| D | gadget_serial.rst | 57 side driver. It runs on a Linux system that has USB device side
66 | Host-Side CDC ACM USB Host |
78 | Device-Side | Gadget | Controller | |
84 On the device-side Linux system, the gadget serial driver looks
87 On the host-side system, the gadget serial device looks like a
92 The host side driver can potentially be any ACM compliant driver
98 With the gadget serial driver and the host side ACM or generic
100 the host and the gadget side systems as if they were connected by a
111 side kernel for "Support for USB Gadgets", for a "USB Peripheral
128 side Linux system. You can add this to the start up scripts, if
[all …]
|
| /Documentation/RCU/ |
| D | lockdep.rst | 8 aware of when each task enters and leaves any flavor of RCU read-side
33 Check for RCU read-side critical section.
35 Check for RCU-bh read-side critical section.
37 Check for RCU-sched read-side critical section.
39 Check for SRCU read-side critical section.
83 1. An RCU read-side critical section (implicit), or
88 RCU read-side critical sections, in case (2) the ->file_lock prevents
99 complain even if this was used in an RCU read-side critical section unless
107 traversal primitives check for being called from within an RCU read-side
111 false and they are called from outside any RCU read-side critical section.
[all …]
|
| D | checklist.rst | 18 tool for the job. Yes, RCU does reduce read-side overhead by
19 increasing write-side overhead, which is exactly why normal uses
28 read-side primitives is critically important.
59 2. Do the RCU read-side critical sections make proper use of
63 under your read-side code, which can greatly increase the
68 rcu_read_lock_sched(), or by the appropriate update-side lock.
72 spinlock also enters an RCU read-side critical section.
78 Letting RCU-protected pointers "leak" out of an RCU read-side
82 *before* letting them out of the RCU read-side critical section.
159 perfectly legal (if redundant) for update-side code to
[all …]
|
| D | whatisRCU.rst | 103 b. Wait for all previous readers to complete their RCU read-side
166 reclaimer that the reader is entering an RCU read-side critical
167 section. It is illegal to block while in an RCU read-side
169 can preempt RCU read-side critical sections. Any RCU-protected
170 data structure accessed during an RCU read-side critical section
176 or interrupts also enters an RCU read-side critical section.
177 Acquiring a spinlock also enters an RCU read-side critical
180 Sleeplocks do *not* enter RCU read-side critical sections.
187 reclaimer that the reader is exiting an RCU read-side critical
189 or interrupts also exits an RCU read-side critical section.
[all …]
|
| D | lockdep-splat.rst | 15 RCU read-side critical section or (2) holding the right update-side lock.
72 This form says that it must be in a plain vanilla RCU read-side critical
84 code was invoked either from within an RCU read-side critical section
89 On the other hand, perhaps we really do need an RCU read-side critical
104 read-side critical section, which again would have suppressed the
|
| D | rcu.rst | 36 read-side critical sections. So, if we remove an item from a
44 RCU read-side critical sections. SRCU also uses CPU-local
45 counters, and permits general blocking within RCU read-side
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | rockchip,rk3399-dmc.yaml | 132 the ODT on the DRAM side and controller side are both disabled.
138 When the DRAM type is DDR3, this parameter defines the DRAM side drive
146 When the DRAM type is DDR3, this parameter defines the DRAM side ODT
154 When the DRAM type is DDR3, this parameter defines the phy side CA line
162 When the DRAM type is DDR3, this parameter defines the PHY side DQ line
170 When the DRAM type is DDR3, this parameter defines the PHY side ODT
180 ODT on the DRAM side and controller side are both disabled.
186 When the DRAM type is LPDDR3, this parameter defines the DRAM side drive
194 When the DRAM type is LPDDR3, this parameter defines the DRAM side ODT
202 When the DRAM type is LPDDR3, this parameter defines the PHY side CA line
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-iio-frequency-admv1013 | 18 side.
24 Read/write value for the Local Oscillatior Feedthrough Offset Calibration Q Positive side.
31 side.
38 side.
|
| /Documentation/litmus-tests/rcu/ |
| D | RCU+sync+read.litmus | 7 * sees all stores done in prior RCU read-side critical sections. Such
8 * read-side critical sections would have ended before the grace period ended.
11 * other things) that an RCU read-side critical section cannot span a grace period.
|
| /Documentation/driver-api/ |
| D | io-mapping.rst | 49 io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
50 migration to make the mapping code work. No caller can rely on this side
53 io_mapping_map_atomic_wc() has the side effect of disabling preemption and
72 undoes the side effects of the mapping functions.
80 This works like io_mapping_map_atomic/local_wc() except it has no side
|
| D | spi.rst | 18 only "master" side interfaces are supported, where Linux talks to SPI
25 a pair of FIFOs connected to dual DMA engines on the other side of the
28 the SPI side of their device as a :c:type:`struct spi_controller
|
| /Documentation/RCU/Design/Requirements/ |
| D | Requirements.rst | 20 updaters do not block readers, which means that RCU's read-side
74 of all pre-existing RCU read-side critical sections. An RCU read-side
77 RCU treats a nested set as one big RCU read-side critical section.
131 | Second, even when using synchronize_rcu(), the other update-side |
173 The RCU read-side critical section in do_something_dlm() works with
190 In order to avoid fatal problems such as deadlocks, an RCU read-side
192 Similarly, an RCU read-side critical section must not contain anything
198 be good to be able to use RCU to coordinate read-side access to linked
370 outermost RCU read-side critical section containing that
387 #. Wait for all pre-existing RCU read-side critical sections to complete
[all …]
|
| /Documentation/networking/ |
| D | tc-queue-filters.rst | 8 to a single queue on both the transmit and receive side.
10 On the transmit side:
22 Likewise, on the receive side, the two filters for selecting set of
|
| D | snmp_counter.rst | 465 connection. So TCP layer sends a RST to the other side, indicate the
476 wait for the in-flight data are acked by the other side, the max wait
485 kernel will send a RST to the other side of the TCP connection.
492 side of the connection, then the app has no relationship with the
494 becomes an orphan socket, kernel waits for the reply of the other side,
497 the other side, and delete the socket, in such situation, kernel will
517 for the fin packet from the other side, kernel could send a RST and
599 know what happened on the receiver side. The sender just waits until
666 counts these two kinds of duplications on both receiver side and
667 sender side.
[all …]
|
| /Documentation/devicetree/bindings/soc/qcom/ |
| D | qcom,aoss-qmp.yaml | 7 title: Qualcomm Always-On Subsystem side channel
13 This binding describes the hardware component responsible for side channel
20 The AOSS side channel exposes control over a set of resources, used to control
81 The AOSS side channel also provides the controls for three cooling devices,
|
| /Documentation/staging/ |
| D | speculation.rst | 17 absence of data in caches. Such state may form side-channels which can be
67 Mitigating speculation side-channels
72 speculation-based side-channels are expected to implement these
76 prevent information from being leaked via side-channels.
|
| /Documentation/devicetree/bindings/mailbox/ |
| D | fsl,mu.yaml | 19 different clocks (from each side of the different peripheral buses).
20 Therefore, the MU must synchronize the accesses from one side to the
88 5 - Tx doorbell channel. With S/W ACK from the other side.
94 fsl,mu-side-b:
95 description: boolean, if present, means it is for side B MU.
|
| /Documentation/ABI/stable/ |
| D | sysfs-driver-aspeed-vuart | 4 Description: Configures which IO port the host side of the UART
12 Description: Configures which interrupt number the host side of
|
| /Documentation/driver-api/usb/ |
| D | gadget.rst | 29 Linux-USB host side.
31 - Sharing data structures and API models with the Linux-USB host side
34 side drivers).
44 Linux "USB device drivers", which are host side proxies for the real USB
50 The gadget API resembles the host side Linux-USB API in that both use
55 host side's current URB framework exposes a number of implementation
58 necessarily different (one side is a hardware-neutral master, the other
60 be usable for an overhead-reduced host side API.
152 side stack, with ``usbcore``, one or more *Host Controller Drivers*
156 That helps the host and device side USB controllers implement the two
[all …]
|
| /Documentation/PCI/endpoint/ |
| D | pci-vntb-howto.rst | 11 be followed in the host side and EP side is given below. For the hardware
133 lspci Output at Host side
146 lspci Output at EP Side / Virtual PCI bus
158 The host side software follows the standard NTB software architecture in Linux.
159 All the existing client side NTB utilities like NTB Transport Client and NTB
|
| /Documentation/devicetree/bindings/net/ |
| D | airoha,en8811h.yaml | 32 side of the lines from the MAC towards the EN881H.
38 side of the lines from EN8811H towards the MAC.
|
| /Documentation/rust/ |
| D | general-information.rst | 70 Abstractions are Rust code wrapping kernel functionality from the C side.
72 In order to use functions and types from the C side, bindings are created.
74 the C side.
77 a ``struct mutex`` from the C side and calls its functions through the bindings.
124 wrapper function to ``rust/helpers/`` to make it available for the Rust side as
|
| /Documentation/userspace-api/media/v4l/ |
| D | vidioc-g-input.rst | 46 to this integer. Side effects are possible. For example inputs may
48 the current standard. Because of these possible side effects
|
12345678910>>...19