| /Linux-v5.10/include/linux/ |
| D | ww_mutex.h | 98 * ww_acquire_init - initialize a w/w acquire context
99 * @ctx: w/w acquire context to initialize
102 * Initializes an context to acquire multiple mutexes of the given w/w class.
114 * Nesting of acquire contexts for _different_ w/w classes is possible, subject
117 * An acquire context must be released with ww_acquire_fini by the same task
147 * ww_acquire_done - marks the end of the acquire phase
148 * @ctx: the acquire context
150 * Marks the end of the acquire phase, any further w/w mutex lock calls using
154 * code and clearly designated the acquire phase from actually using the locked
168 * ww_acquire_fini - releases a w/w acquire context
[all …]
|
| D | atomic.h | 16 * - Acquire: Provides ACQUIRE semantics, _acquire suffix.
20 * For compound atomics performing both a load and a store, ACQUIRE
25 * See Documentation/memory-barriers.txt for ACQUIRE/RELEASE definitions.
35 * The idea here is to build acquire/release variants by adding explicit
|
| D | local_lock.h | 13 * local_lock - Acquire a per CPU local lock
19 * local_lock_irq - Acquire a per CPU local lock and disable interrupts
25 * local_lock_irqsave - Acquire a per CPU local lock, save and disable
|
| /Linux-v5.10/tools/memory-model/ |
| D | linux-kernel.def | 12 // Release Acquire and friends
14 smp_load_acquire(X) __load{acquire}(*X)
33 xchg_acquire(X,V) __xchg{acquire}(X,V)
36 cmpxchg_acquire(X,V,W) __cmpxchg{acquire}(X,V,W)
70 atomic_add_return_acquire(V,X) __atomic_op_return{acquire}(X,+,V)
74 atomic_fetch_add_acquire(V,X) __atomic_fetch_op{acquire}(X,+,V)
79 atomic_inc_return_acquire(X) __atomic_op_return{acquire}(X,+,1)
83 atomic_fetch_inc_acquire(X) __atomic_fetch_op{acquire}(X,+,1)
88 atomic_sub_return_acquire(V,X) __atomic_op_return{acquire}(X,-,V)
92 atomic_fetch_sub_acquire(V,X) __atomic_fetch_op{acquire}(X,-,V)
[all …]
|
| D | linux-kernel.bell | 18 'acquire (*smp_load_acquire*) ||
20 instructions R[{'once,'acquire,'noreturn}]
22 instructions RMW[{'once,'acquire,'release}]
82 let Marked = (~M) | IW | Once | Release | Acquire | domain(rmw) | range(rmw) |
|
| /Linux-v5.10/kernel/locking/ |
| D | semaphore.c | 23 * The ->count variable represents how many more tasks can acquire this
43 * down - acquire the semaphore
46 * Acquires the semaphore. If no more tasks are allowed to acquire the
67 * down_interruptible - acquire the semaphore unless interrupted
70 * Attempts to acquire the semaphore. If no more tasks are allowed to
71 * acquire the semaphore, calling this function will put the task to sleep.
92 * down_killable - acquire the semaphore unless killed
95 * Attempts to acquire the semaphore. If no more tasks are allowed to
96 * acquire the semaphore, calling this function will put the task to sleep.
118 * down_trylock - try to acquire the semaphore, without waiting
[all …]
|
| D | mcs_spinlock.h | 9 * to acquire the lock spinning on a local variable.
26 * Using smp_cond_load_acquire() provides the acquire semantics
58 * In order to acquire the lock, the caller should declare a local node and
76 * observation of @node. And to provide the ACQUIRE ordering associated in mcs_spin_lock()
84 * However, since this thread can immediately acquire the lock in mcs_spin_lock()
99 * was used to acquire the lock.
|
| D | qrwlock.c | 18 * queued_read_lock_slowpath - acquire read lock of a queue rwlock
30 * so spin with ACQUIRE semantics until the lock is available in queued_read_lock_slowpath()
45 * The ACQUIRE semantics of the following spinning code ensure in queued_read_lock_slowpath()
59 * queued_write_lock_slowpath - acquire write lock of a queue rwlock
67 /* Try to acquire the lock directly if no reader is present */ in queued_write_lock_slowpath()
|
| D | rwsem.c | 45 * to acquire the lock via optimistic spinning, but not readers. Similar
76 * groups that contain readers that acquire the lock together smaller
83 * nonspinnable bit for a given rwsem after they fail to acquire the lock
85 * acquire the write lock. Similarly, readers that observe the setting
87 * nonspinnable bits when they acquire the read lock via the wakeup path.
90 * a writer is able to acquire the rwsem in the fast path or somehow a
485 * to acquire the lock at the same time irrespective of their order in rwsem_mark_wake()
486 * in the queue. The writers acquire the lock according to their in rwsem_mark_wake()
605 * Try to acquire read lock before the reader is put on wait queue.
629 * Try to acquire write lock before the writer has been put on wait queue.
[all …]
|
| D | mutex.c | 132 * past the point where we acquire it. This would be possible in __mutex_trylock_or_owner()
222 * __mutex_trylock() provides a matching ACQUIRE semantics for the handoff.
259 * mutex_lock - acquire the mutex
310 * If this WARN_ON triggers, you used ww_mutex_lock to acquire, in ww_mutex_lock_acquired()
325 * acquire a different ww_mutex? Bad! in ww_mutex_lock_acquired()
473 * and keep spinning, or it will acquire wait_lock, add itself in ww_mutex_set_context_fastpath()
654 * acquire the mutex all at once, the spinners need to take a in mutex_optimistic_spin()
664 /* Try to acquire the mutex... */ in mutex_optimistic_spin()
749 * ww_mutex_lock* functions (with or without an acquire context). It is
750 * forbidden to release the locks after releasing the acquire context.
[all …]
|
| /Linux-v5.10/tools/memory-model/litmus-tests/ |
| D | README | 46 and load-acquire replaced with READ_ONCE().
49 Can a release-acquire chain order a prior store against
58 Does a release-acquire pair suffice for the load-buffering
64 and load-acquire replaced with READ_ONCE().
71 in one process, and use an acquire load followed by a pair of
76 acquire load followed by a pair of spin_is_locked() calls
87 As below, but with a release-acquire chain.
126 As below, but without the smp_wmb() and acquire load.
129 Can a smp_wmb(), instead of a release, and an acquire order
149 Is the ordering provided by a release-acquire chain sufficient
[all …]
|
| D | ISA2+pooncerelease+poacquirerelease+poacquireonce.litmus | 6 * This litmus test demonstrates that a release-acquire chain suffices
8 * that the release-acquire chain suffices is because in all but one
11 * (AKA non-rf) link, so release-acquire is all that is needed.
|
| /Linux-v5.10/Documentation/sound/cards/ |
| D | img-spdif-in.rst | 19 * name='SPDIF In Multi Frequency Acquire',index=0
20 * name='SPDIF In Multi Frequency Acquire',index=1
21 * name='SPDIF In Multi Frequency Acquire',index=2
22 * name='SPDIF In Multi Frequency Acquire',index=3
47 * name='SPDIF In Lock Acquire Threshold',index=0
|
| /Linux-v5.10/include/drm/ |
| D | drm_modeset_lock.h | 33 * @ww_ctx: base acquire ctx
39 * Each thread competing for a set of locks must use one acquire
143 * DRM_MODESET_LOCK_ALL_BEGIN - Helper to acquire modeset locks
145 * @ctx: local modeset acquire context, will be dereferenced
158 * Drivers can acquire additional modeset locks. If any lock acquisition
178 * @ctx: local modeset acquire context, will be dereferenced
189 * successfully acquire the locks, ret will be whatever your code sets it to. If
190 * there is a deadlock or other failure with acquire or backoff, ret will be set
|
| /Linux-v5.10/Documentation/driver-api/soundwire/ |
| D | locking.rst | 42 a. Acquire Message lock.
59 <-------------------------------+ a. Acquire Message lock
72 1. Acquire lock for Bus instance associated with Master 1.
76 a. Acquire Message lock.
93 <-------------------------------+ 1. Acquire bus lock
98 <-------------------------------+ a. Acquire Message lock
|
| /Linux-v5.10/drivers/gpu/drm/ |
| D | drm_modeset_lock.c | 34 * to use &ww_mutex and acquire-contexts to avoid deadlocks. But because
36 * of extra utility/tracking out of our acquire-ctx. This is provided
190 * drm_modeset_acquire_init - initialize acquire context
191 * @ctx: the acquire context
211 * drm_modeset_acquire_fini - cleanup acquire context
212 * @ctx: the acquire context
222 * @ctx: the acquire context
224 * Drop all locks currently held against this acquire context.
284 * @ctx: the acquire context
323 * @ctx: acquire ctx
[all …]
|
| /Linux-v5.10/Documentation/locking/ |
| D | ww-mutex-design.rst | 63 Acquire context: To ensure eventual forward progress it is important the a task
64 trying to acquire locks doesn't grab a new reservation id, but keeps the one it
66 acquire context. Furthermore the acquire context keeps track of debugging state
67 to catch w/w mutex interface abuse. An acquire context is representing a
71 w/w mutexes, since it is required to initialize the acquire context. The lock
74 Furthermore there are three different class of w/w lock acquire functions:
99 * Functions to only acquire a single w/w mutex, which results in the exact same
103 Again this is not strictly required. But often you only want to acquire a
104 single lock in which case it's pointless to set up an acquire context (and so
119 Three different ways to acquire locks within the same w/w class. Common
[all …]
|
| D | futex-requeue-pi.rst | 91 to be able to acquire the rt_mutex before returning to user space.
93 acquire the rt_mutex as it would open a race window between the
99 allow the requeue code to acquire an uncontended rt_mutex on behalf
115 requeueing, futex_requeue() attempts to acquire the requeue target
127 tasks as it can acquire the lock for, which in the majority of cases
129 either pthread_cond_broadcast() or pthread_cond_signal() acquire the
|
| D | mutex-design.rst | 40 (i) fastpath: tries to atomically acquire the lock by cmpxchg()ing the owner with
54 to acquire the lock spinning on a local variable. It avoids expensive
97 - Point-of-acquire tracking, symbolic lookup of function names,
115 Acquire the mutex, uninterruptible::
121 Acquire the mutex, interruptible::
127 Acquire the mutex, interruptible, if dec to 0::
|
| /Linux-v5.10/drivers/net/ethernet/intel/igc/ |
| D | igc_i225.c | 9 * igc_get_hw_semaphore_i225 - Acquire hardware semaphore
12 * Acquire the necessary semaphores for exclusive access to the EEPROM.
35 * igc_get_hw_semaphore_i225 - Acquire hardware semaphore
38 * Acquire the HW semaphore to access the PHY or NVM
102 * igc_acquire_swfw_sync_i225 - Acquire SW/FW semaphore
104 * @mask: specifies which semaphore to acquire
106 * Acquire the SW/FW semaphore to access the PHY or NVM. The mask
150 * @mask: specifies which semaphore to acquire
193 status = hw->nvm.ops.acquire(hw); in igc_read_nvm_srrd_i225()
292 status = hw->nvm.ops.acquire(hw); in igc_write_nvm_srwr_i225()
[all …]
|
| /Linux-v5.10/Documentation/translations/ko_KR/ |
| D | memory-barriers.txt | 104 - Acquire vs 메모리 액세스.
489 (5) ACQUIRE 오퍼레이션.
491 이 타입의 오퍼레이션은 단방향의 투과성 배리어처럼 동작합니다. ACQUIRE
492 오퍼레이션 뒤의 모든 메모리 오퍼레이션들이 ACQUIRE 오퍼레이션 후에
495 ACQUIRE 오퍼레이션에 포함됩니다.
497 ACQUIRE 오퍼레이션 앞의 메모리 오퍼레이션들은 ACQUIRE 오퍼레이션 완료 후에
500 ACQUIRE 오퍼레이션은 거의 항상 RELEASE 오퍼레이션과 짝을 지어 사용되어야
515 ACQUIRE 와 RELEASE 오퍼레이션의 사용은 일반적으로 다른 메모리 배리어의
516 필요성을 없앱니다. 또한, RELEASE+ACQUIRE 조합은 범용 메모리 배리어처럼
519 뒤이어 같은 변수에 대해 수행된 ACQUIRE 오퍼레이션을 뒤따르는 메모리
[all …]
|
| /Linux-v5.10/drivers/gpu/drm/i915/ |
| D | intel_wakeref.h | 67 * intel_wakeref_get: Acquire the wakeref
70 * Acquire a hold on the wakeref. The first user to do so, will acquire
91 * __intel_wakeref_get: Acquire the wakeref, again
107 * intel_wakeref_get_if_in_use: Acquire the wakeref
110 * Acquire a hold on the wakeref, but only if the wakeref is already
|
| /Linux-v5.10/include/asm-generic/ |
| D | qrwlock.h | 34 * queued_read_trylock - try to acquire read lock of a queue rwlock
53 * queued_write_trylock - try to acquire write lock of a queue rwlock
69 * queued_read_lock - acquire read lock of a queue rwlock
85 * queued_write_lock - acquire write lock of a queue rwlock
|
| /Linux-v5.10/Documentation/ |
| D | memory-barriers.txt | 466 (5) ACQUIRE operations.
469 operations after the ACQUIRE operation will appear to happen after the
470 ACQUIRE operation with respect to the other components of the system.
471 ACQUIRE operations include LOCK operations and both smp_load_acquire()
474 Memory operations that occur before an ACQUIRE operation may appear to
477 An ACQUIRE operation should almost always be paired with a RELEASE
492 The use of ACQUIRE and RELEASE operations generally precludes the need
493 for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
495 ACQUIRE on a given variable, all memory accesses preceding any prior
501 This means that ACQUIRE acts as a minimal "acquire" operation and
[all …]
|
| /Linux-v5.10/drivers/remoteproc/ |
| D | qcom_q6v5.c | 220 dev_err(&pdev->dev, "failed to acquire wdog IRQ\n"); in qcom_q6v5_init()
233 dev_err(&pdev->dev, "failed to acquire fatal IRQ\n"); in qcom_q6v5_init()
246 dev_err(&pdev->dev, "failed to acquire ready IRQ\n"); in qcom_q6v5_init()
259 dev_err(&pdev->dev, "failed to acquire handover IRQ\n"); in qcom_q6v5_init()
273 dev_err(&pdev->dev, "failed to acquire stop-ack IRQ\n"); in qcom_q6v5_init()
279 dev_err(&pdev->dev, "failed to acquire stop state\n"); in qcom_q6v5_init()
|
