Home
last modified time | relevance | path

Searched refs:P0 (Results 1 – 25 of 92) sorted by relevance

1234

/Linux-v6.6/tools/memory-model/litmus-tests/
Ddep+plain.litmus8 * The data stored to *z1 and *z2 by P0() originates from P0()'s
10 * conditional of P0()'s if-statement creates a control dependency
11 * from that READ_ONCE() to P0()'s WRITE_ONCE().
16 P0(int *x, int *y, int *z1, int *z2)
DISA2+pooncerelease+poacquirerelease+poacquireonce.litmus7 * to order P0()'s initial write against P2()'s final read. The reason
9 * case (P2() to P0()), each process reads from the preceding process's
16 P0(int *x, int *y)
DZ6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus9 * P0's write, which means that there are two non-rf links: P1() to P2()
11 * to P0() is a read-to-write link (AKA a "from-reads" or just "fr" link).
19 P0(int *x, int *y)
DS+poonceonces.litmus6 * Starting with a two-process release-acquire chain ordering P0()'s
14 P0(int *x, int *y)
DISA2+pooncelock+pooncelock+pombonce.litmus7 * (in P0() and P1()) is visible to external process P2().
12 P0(int *x, int *y, spinlock_t *mylock)
DREADME192 P0(int *x, int *y)
216 P0()'s WRITE_ONCE() is read by its first READ_ONCE(), which is a
217 reads-from link (rf) and internal to the P0() process. This is
223 P0()'s second access is a READ_ONCE(), as opposed to (for example)
226 P0()'s third access is also a READ_ONCE(), but to y rather than x.
227 This is related to P0()'s second access by program order ("po"),
229 The resulting descriptor is "PodRR". Because P0()'s third access is
232 A from-read ("fre") relation links P0()'s third to P1()'s first
237 The remainder of P1() is similar to P0(), which means we add
239 P0()'s first access, which is WRITE_ONCE(), so we add "Fre Once".
DCoWW+poonceonce.litmus12 P0(int *x)
DCoRR+poonceonce+Once.litmus12 P0(int *x)
DLB+poonceonces.litmus12 P0(int *x, int *y)
DS+fencewmbonceonce+poacquireonce.litmus12 P0(int *x, int *y)
DCoRW+poonceonce+Once.litmus12 P0(int *x)
DCoWR+poonceonce+Once.litmus12 P0(int *x)
DMP+poonceonces.litmus12 P0(int *buf, int *flag) // Producer
DR+poonceonces.litmus13 P0(int *x, int *y)
DMP+pooncerelease+poacquireonce.litmus13 P0(int *buf, int *flag) // Producer
DLB+poacquireonce+pooncerelease.litmus13 P0(int *x, int *y)
DSB+poonceonces.litmus13 P0(int *x, int *y)
DMP+fencewmbonceonce+fencermbonceonce.litmus13 P0(int *buf, int *flag) // Producer
/Linux-v6.6/drivers/ata/
Data_piix.c106 P0 = 0, /* port 0 */ enumerator
344 { P0, NA, P1, NA }, /* 000b */
345 { P1, NA, P0, NA }, /* 001b */
348 { P0, P1, IDE, IDE }, /* 100b */
349 { P1, P0, IDE, IDE }, /* 101b */
350 { IDE, IDE, P0, P1 }, /* 110b */
351 { IDE, IDE, P1, P0 }, /* 111b */
360 { P0, P2, P1, P3 }, /* 00b */
362 { P0, P2, IDE, IDE }, /* 10b */
377 { P0, P2, NA, NA }, /* 00b */
[all …]
/Linux-v6.6/arch/hexagon/kernel/
Dvm_entry.S284 P0 = tstbit(R0, #HVM_VMEST_UM_SFT); define
285 if (!P0.new) jump:nt restore_all;
307 P0 = cmp.eq(R0, #0); if (!P0.new) jump:nt check_work_pending; define
368 P0 = cmp.eq(R24, #0); define
372 if (P0) jump check_work_pending
/Linux-v6.6/arch/arm/boot/dts/aspeed/
Daspeed-bmc-amd-ethanolx.dts140 /*P0-P7*/ "P0_VDD_CORE_RUN_VRHOT","P0_VDD_SOC_RUN_VRHOT",
159 //APML for P0
184 //P0 Power regulators
194 //P0/P1 Thermal diode
/Linux-v6.6/tools/memory-model/Documentation/
Dexplanation.txt116 P0()
132 Here the P0() function represents the interrupt handler running on one
135 Thus, P0 stores the data in buf and then sets flag. Meanwhile, P1
163 instance, P1 might run entirely before P0 begins, in which case r1 and
164 r2 will both be 0 at the end. Or P0 might run entirely before P1
168 routines run concurrently. One possibility is that P1 runs after P0's
197 Since r1 = 1, P0 must store 1 to flag before P1 loads 1 from
203 P1 must load 0 from buf before P0 stores 1 to it; otherwise r2
207 P0 stores 1 to buf before storing 1 to flag, since it executes
210 Since an instruction (in this case, P0's store to flag) cannot
[all …]
Dlitmus-tests.txt72 5 P0(int *x, int *y)
114 The name of the first process is "P0" and that of the second "P1".
123 names are significant. The fact that both P0() and P1() have a formal
125 same global variable, also named "x". So the "int *x, int *y" on P0()
128 by reference, hence "P0(int *x, int *y)", but *never* "P0(int x, int y)".
130 P0() has no local variables, but P1() has two of them named "r0" and "r1".
145 The P0() process does "WRITE_ONCE(*x, 1)" on line 7. Because "x" is a
146 pointer in P0()'s parameter list, this does an unordered store to global
148 is also in P0()'s parameter list, this does a release store to global
156 reference the same global variables that are used by P0().
[all …]
/Linux-v6.6/Documentation/translations/zh_CN/scheduler/
Dschedutil.rst65 f_cur := ----- * P0
70 P0; 其它情况
/Linux-v6.6/Documentation/litmus-tests/atomic/
DAtomic-RMW-ops-are-atomic-WRT-atomic_set.litmus14 P0(atomic_t *v)

1234