| /linux/arch/powerpc/platforms/8xx/ |
| H A D | Kconfig | 132 Help not implemented yet, coming soon.
140 Help not implemented yet, coming soon.
145 Help not implemented yet, coming soon.
150 Help not implemented yet, coming soon.
|
| /linux/tools/testing/selftests/ftrace/test.d/trigger/ |
| H A D | trigger-hist-poll.tc | 17 # returns soon with POLLIN | POLLOUT, but not POLLPRI.
42 echo "poll exits too soon"
64 echo "poll exits too soon"
|
| /linux/Documentation/locking/ |
| H A D | hwspinlock.rst | 97 soon as possible, in order to minimize remote cores polling on the
113 release the hwspinlock as soon as possible.
130 release the hwspinlock as soon as possible.
179 caller must not sleep, and is advised to release the hwspinlock as soon as
197 release the hwspinlock as soon as possible.
214 to release the hwspinlock as soon as possible.
|
| /linux/include/linux/ |
| H A D | hwspinlock.h | 165 * as soon as possible.
185 * to release the hwspinlock as soon as possible.
240 * as soon as possible. This is required in order to minimize remote cores
263 * not sleep, and is advised to release the hwspinlock as soon as possible.
286 * hwspinlock as soon as possible.
354 * as soon as possible.
|
| H A D | mii_timestamper.h | 21 * netif_rx() as soon as a timestamp becomes available. One of
27 * as soon as a timestamp becomes available. One of the PTP_CLASS_
|
| H A D | initrd.h | 6 #define INITRD_MINOR 250 /* shouldn't collide with /dev/ram* too soon ... */
|
| /linux/Documentation/networking/ |
| H A D | x25-iface.rst | 37 confirmation message should be returned as soon as possible.
42 confirmation message should be returned as soon as possible.
|
| /linux/tools/perf/pmu-events/arch/x86/jaketown/ |
| H A D | uncore-memory.json | 411 "PublicDescription": "Counts the number of cycles that the Read Pending Queue is not empty. This can then be used to calculate the average occupancy (in conjunction with the Read Pending Queue Occupancy count). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This filter is to be used in conjunction with the occupancy filter so that one can correctly track the average occupancies for schedulable entries and scheduled requests.",
420 "PublicDescription": "Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
429 "PublicDescription": "Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
447 "PublicDescription": "Counts the number of cycles that the Write Pending Queue is not empty. This can then be used to calculate the average queue occupancy (in conjunction with the WPQ Occupancy Accumulation count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after being issued to DRAM. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have 'posted' to the iMC. This is not to be confused with actually performing the write to DRAM. Therefore, the average latency for this queue is actually not useful for deconstruction intermediate write latencies.",
456 "PublicDescription": "Counts the number of allocations into the Write Pending Queue. This can then be used to calculate the average queuing latency (in conjunction with the WPQ occupancy count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after being issued to DRAM. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have 'posted' to the iMC.",
465 "PublicDescription": "Accumulates the occupancies of the Write Pending Queue each cycle. This can then be used to calculate both the average queue occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after being issued to DRAM. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have 'posted' to the iMC. This is not to be confused with actually performing the write to DRAM. Therefore, the average latency for this queue is actually not useful for deconstruction intermediate write latencies. So, we provide filtering based on if the request has posted or not. By using the 'not posted' filter, we can track how long writes spent in the iMC before completions were sent to the HA. The 'posted' filter, on the other hand, provides information about how much queueing is actually happening in the iMC for writes before they are actually issued to memory. High average occupancies will generally coincide with high write major mode counts.",
|
| /linux/drivers/net/wireguard/ |
| H A D | queueing.h | 171 * packet as soon as it can. in wg_queue_enqueue_per_device_and_peer()
182 /* We take a reference, because as soon as we call atomic_set, the in wg_queue_enqueue_per_peer_tx()
195 /* We take a reference, because as soon as we call atomic_set, the in wg_queue_enqueue_per_peer_rx()
|
| /linux/Documentation/w1/slaves/ |
| H A D | w1_ds28e17.rst | 40 This sets up the default I2C speed a DS28E17 get configured for as soon
43 as soon the "w1_ds28e17" driver notices a freshly connected, or
|
| /linux/arch/arm/mach-omap1/ |
| H A D | board-ams-delta.c | 481 * obtained from GPIO chip as soon as the chip is available.
495 * with FIQ buffer address as soon as FIQ is initialized.
506 * with serio dev_name() as soon as the serio device is registered.
591 * The function may be called as soon as OMAP GPIO devices are probed.
646 * GPIO driver as soon as it is ready.
699 * As soon as regulator consumers have been registered, assign their in ams_delta_init()
713 * As soon as GPIO consumers have been registered, assign in ams_delta_init()
|
| /linux/tools/perf/pmu-events/arch/x86/icelakex/ |
| H A D | uncore-memory.json | 741 "PublicDescription": "Read Pending Queue Not Empty : Counts the number of cycles that the Read Pending Queue is not empty. This can then be used to calculate the average occupancy (in conjunction with the Read Pending Queue Occupancy count). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This filter is to be used in conjunction with the occupancy filter so that one can correctly track the average occupancies for schedulable entries and scheduled requests.",
752 "PublicDescription": "Read Pending Queue Not Empty : Counts the number of cycles that the Read Pending Queue is not empty. This can then be used to calculate the average occupancy (in conjunction with the Read Pending Queue Occupancy count). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This filter is to be used in conjunction with the occupancy filter so that one can correctly track the average occupancies for schedulable entries and scheduled requests.",
762 "PublicDescription": "Read Pending Queue Allocations : Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
772 "PublicDescription": "Read Pending Queue Allocations : Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
782 "PublicDescription": "Read Pending Queue Occupancy : Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
791 "PublicDescription": "Read Pending Queue Occupancy : Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
1789 "PublicDescription": "Write Pending Queue Not Empty : Counts the number of cycles that the Write Pending Queue is not empty. This can then be used to calculate the average queue occupancy (in conjunction with the WPQ Occupancy Accumulation count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued to DRAM. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have posted to the iMC. This is not to be confused with actually performing the write to DRAM. Therefore, the average latency for this queue is actually not useful for deconstruction intermediate write latencies.",
1800 "PublicDescription": "Write Pending Queue Not Empty : Counts the number of cycles that the Write Pending Queue is not empty. This can then be used to calculate the average queue occupancy (in conjunction with the WPQ Occupancy Accumulation count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued to DRAM. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon the
[all...] |
| /linux/fs/nfsd/ |
| H A D | nfsd.h | 396 * HIDDEN (unlikely to be supported any time soon)
397 * MIMETYPE (unlikely to be supported any time soon)
399 * SYSTEM (unlikely to be supported any time soon)
400 * TIME_BACKUP (unlikely to be supported any time soon)
401 * TIME_CREATE (unlikely to be supported any time soon)
|
| /linux/drivers/gpu/drm/exynos/ |
| H A D | exynos_drm_ipp.h | 36 * task as soon as possible (i.e. as soon as it can stop the device
|
| /linux/Documentation/hwmon/ |
| H A D | via686a.rst | 19 - Jonathan Teh Soon Yew <j.teh@iname.com>
50 as soon as it drops below the hysteresis value.
|
| H A D | f71882fg.rst | 76 Datasheet: Should become available on the Fintek website soon
84 Datasheet: Should become available on the Fintek website soon
|
| /linux/Documentation/userspace-api/media/cec/ |
| H A D | cec-pin-error-inj.rst | 66 # <op>[,<mode>] tx-early-eom set the EOM bit one byte too soon
189 As soon as a start bit has been received the CEC adapter will switch
216 as soon as the receiver NACKs a byte the transmit will stop, but the
233 Set the EOM bit one byte too soon. This obviously only works for messages
344 Transmit a single custom pulse as soon as the CEC bus is idle.
|
| /linux/Documentation/arch/arm/ |
| H A D | microchip.rst | 150 Coming soon
158 Coming soon
|
| /linux/tools/perf/pmu-events/arch/x86/sapphirerapids/ |
| H A D | uncore-memory.json | 2398 "PublicDescription": "Read Pending Queue Allocations: Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
2409 "PublicDescription": "Read Pending Queue Allocations: Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
2420 "PublicDescription": "Read Pending Queue Occupancy: Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
2430 "PublicDescription": "Read Pending Queue Occupancy: Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
2440 "PublicDescription": "Write Pending Queue Allocations: Counts the number of allocations into the Write Pending Queue. This can then be used to calculate the average queuing latency (in conjunction with the WPQ occupancy count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have posted to the iMC.",
2451 "PublicDescription": "Write Pending Queue Allocations: Counts the number of allocations into the Write Pending Queue. This can then be used to calculate the average queuing latency (in conjunction with the WPQ occupancy count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have posted to the iMC.",
2462 "PublicDescription": "Write Pending Queue Occupancy: Accumulates the occupancies of the Write Pending Queue each cycle. This can then be used to calculate both the average queue occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after being issued to memory. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon the
[all...] |
| /linux/tools/perf/pmu-events/arch/x86/emeraldrapids/ |
| H A D | uncore-memory.json | 2398 "PublicDescription": "Read Pending Queue Allocations: Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
2409 "PublicDescription": "Read Pending Queue Allocations: Counts the number of allocations into the Read Pending Queue. This queue is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory. This includes both ISOCH and non-ISOCH requests.",
2420 "PublicDescription": "Read Pending Queue Occupancy: Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
2430 "PublicDescription": "Read Pending Queue Occupancy: Accumulates the occupancies of the Read Pending Queue each cycle. This can then be used to calculate both the average occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The RPQ is used to schedule reads out to the memory controller and to track the requests. Requests allocate into the RPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after the CAS command has been issued to memory.",
2440 "PublicDescription": "Write Pending Queue Allocations: Counts the number of allocations into the Write Pending Queue. This can then be used to calculate the average queuing latency (in conjunction with the WPQ occupancy count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have posted to the iMC.",
2451 "PublicDescription": "Write Pending Queue Allocations: Counts the number of allocations into the Write Pending Queue. This can then be used to calculate the average queuing latency (in conjunction with the WPQ occupancy count). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the CHA to the iMC. They deallocate after being issued. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon they have posted to the iMC.",
2462 "PublicDescription": "Write Pending Queue Occupancy: Accumulates the occupancies of the Write Pending Queue each cycle. This can then be used to calculate both the average queue occupancy (in conjunction with the number of cycles not empty) and the average latency (in conjunction with the number of allocations). The WPQ is used to schedule write out to the memory controller and to track the writes. Requests allocate into the WPQ soon after they enter the memory controller, and need credits for an entry in this buffer before being sent from the HA to the iMC. They deallocate after being issued to memory. Write requests themselves are able to complete (from the perspective of the rest of the system) as soon the
[all...] |
| /linux/Documentation/arch/s390/ |
| H A D | 3270.rst | 52 one another. ReIPL as soon as possible after running the configuration
97 login prompts appear on your 3270s as soon as boot is complete (or
98 with emulated 3270s, as soon as you dial into your vm guest using the
|
| /linux/arch/powerpc/platforms/52xx/ |
| H A D | mpc52xx_pm.c | 94 sram_size = 0x4000; /* bestcomm driver soon */ in mpc52xx_pm_prepare()
131 /* don't let DEC expire any time soon */ in mpc52xx_pm_enter()
|
| /linux/drivers/md/dm-vdo/ |
| H A D | action-manager.c | 286 * The action will be launched immediately if there is no current action, or as soon as the current
313 * The operation's action will be launched immediately if there is no current action, or as soon as
344 * The operation's action will be launched immediately if there is no current action, or as soon as
|
| /linux/Documentation/devicetree/bindings/watchdog/ |
| H A D | xlnx,versal-wwdt.yaml | 17 too soon and a period that is not too late. The WWDT has to be
|
| /linux/Documentation/userspace-api/media/drivers/ |
| H A D | omap3isp-uapi.rst | 157 done before streaming, it will take effect as soon as the pipeline starts to
158 stream. If the pipeline is already streaming, it will take effect as soon as
|