Searched +full:idle +full:- +full:states (Results 1 – 25 of 63) sorted by relevance
123
| /Documentation/devicetree/bindings/arm/ |
| D | idle-states.txt | 2 ARM idle states binding description
6 1 - Introduction
10 where cores can be put in different low-power states (ranging from simple
11 wfi to power gating) according to OS PM policies. The CPU states representing
12 the range of dynamic idle states that a processor can enter at run-time, can be
14 to enter/exit specific idle states on a given processor.
17 power states an ARM CPU can be put into are identified by the following list:
19 - Running
20 - Idle_standby
21 - Idle_retention
[all …]
|
| D | cpu-capacity.txt | 6 1 - Introduction
15 2 - CPU capacity definition
19 heterogeneity. Such heterogeneity can come from micro-architectural differences
23 capture a first-order approximation of the relative performance of CPUs.
29 * A "single-threaded" or CPU affine benchmark
43 3 - capacity-dmips-mhz
46 capacity-dmips-mhz is an optional cpu node [1] property: u32 value
51 capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu
54 available, final capacities are calculated by directly using capacity-dmips-
58 4 - Examples
[all …]
|
| D | psci.yaml | 1 # SPDX-License-Identifier: GPL-2.0
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
15 processors") can be used by Linux to initiate various CPU-centric power
25 r0 => 32-bit Function ID / return value
26 {r1 - r3} => Parameters
37 - description:
41 - description:
43 const: arm,psci-0.2
[all …]
|
| /Documentation/devicetree/bindings/powerpc/opal/ |
| D | power-mgt.txt | 1 IBM Power-Management Bindings
5 idle states. The description of these idle states is exposed via the
6 node @power-mgt in the device-tree by the firmware.
9 ----------------
10 Typically each idle state has the following associated properties:
12 - name: The name of the idle state as defined by the firmware.
14 - flags: indicating some aspects of this idle states such as the
15 extent of state-loss, whether timebase is stopped on this
16 idle states and so on. The flag bits are as follows:
18 - exit-latency: The latency involved in transitioning the state of the
[all …]
|
| /Documentation/devicetree/bindings/arm/msm/ |
| D | qcom,idle-state.txt | 1 QCOM Idle States for cpuidle driver
3 ARM provides idle-state node to define the cpuidle states, as defined in [1].
4 cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
5 states. Idle states have different enter/exit latency and residency values.
6 The idle states supported by the QCOM SoC are defined as -
18 hierarchy to enter standby states, when all cpus are idle. An interrupt brings
34 between the time it enters idle and the next known wake up. SPC mode is used
37 sequence for this idle state is programmed to power down the supply to the
44 code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
50 be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | cpuidle.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 CPU Idle Time Management
19 Modern processors are generally able to enter states in which the execution of
21 memory or executed. Those states are the *idle* states of the processor.
23 Since part of the processor hardware is not used in idle states, entering them
27 CPU idle time management is an energy-efficiency feature concerned about using
28 the idle states of processors for this purpose.
31 ------------
33 CPU idle time management operates on CPUs as seen by the *CPU scheduler* (that
37 software as individual single-core processors. In other words, a CPU is an
[all …]
|
| D | strategies.rst | 1 .. SPDX-License-Identifier: GPL-2.0
13 The Linux kernel supports two major high-level power management strategies.
15 One of them is based on using global low-power states of the whole system in
17 significantly reduced, referred to as :doc:`sleep states <sleep-states>`. The
18 kernel puts the system into one of these states when requested by user space
21 user space code can run. Because sleep states are global and the whole system
23 :doc:`system-wide power management <system-wide>`.
25 The other strategy, referred to as the :doc:`working-state power management
26 <working-state>`, is based on adjusting the power states of individual hardware
30 a metastate covering a range of different power states of the system in which
[all …]
|
| D | sleep-states.rst | 1 .. SPDX-License-Identifier: GPL-2.0
5 System Sleep States
13 Sleep states are global low-power states of the entire system in which user
18 Sleep States That Can Be Supported
22 the Linux kernel can support up to four system sleep states, including
23 hibernation and up to three variants of system suspend. The sleep states that
28 Suspend-to-Idle
29 ---------------
31 This is a generic, pure software, light-weight variant of system suspend (also
33 runtime idle by freezing user space, suspending the timekeeping and putting all
[all …]
|
| /Documentation/driver-api/pm/ |
| D | cpuidle.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 CPU Idle Time Management
18 CPU Idle Time Management Subsystem
23 cores) is idle after an interrupt or equivalent wakeup event, which means that
24 there are no tasks to run on it except for the special "idle" task associated
26 belongs to. That can be done by making the idle logical CPU stop fetching
28 depended on by it into an idle state in which they will draw less power.
30 However, there may be multiple different idle states that can be used in such a
33 particular idle state. That is the role of the CPU idle time management
40 units: *governors* responsible for selecting idle states to ask the processor
[all …]
|
| /Documentation/devicetree/bindings/power/ |
| D | power_domain.txt | 12 #power-domain-cells property in the PM domain provider node.
17 - #power-domain-cells : Number of cells in a PM domain specifier;
23 - power-domains : A phandle and PM domain specifier as defined by bindings of
32 - domain-idle-states : A phandle of an idle-state that shall be soaked into a
33 generic domain power state. The idle state definitions are
34 compatible with domain-idle-state specified in [1]. phandles
35 that are not compatible with domain-idle-state will be
37 The domain-idle-state property reflects the idle state of this PM domain and
38 not the idle states of the devices or sub-domains in the PM domain. Devices
39 and sub-domains have their own idle-states independent of the parent
[all …]
|
| /Documentation/devicetree/bindings/mux/ |
| D | adi,adgs1408.txt | 4 - compatible : Should be one of
7 * Standard mux-controller bindings as described in mux-controller.txt
10 - gpio-controller : if present, #gpio-cells is required.
11 - #gpio-cells : should be <2>
12 - First cell is the GPO line number, i.e. 0 to 3
14 - Second cell is used to specify active high (0)
18 - idle-state : if present, the state that the mux controller will have
19 when idle. The special state MUX_IDLE_AS_IS is the default and
22 States 0 through 7 correspond to signals S1 through S8 in the datasheet.
23 For ADGS1409 only states 0 to 3 are available.
[all …]
|
| D | adi,adg792a.txt | 4 - compatible : "adi,adg792a" or "adi,adg792g"
5 - #mux-control-cells : <0> if parallel (the three muxes are bound together
8 * Standard mux-controller bindings as described in mux-controller.txt
11 - gpio-controller : if present, #gpio-cells below is required.
12 - #gpio-cells : should be <2>
13 - First cell is the GPO line number, i.e. 0 or 1
14 - Second cell is used to specify active high (0)
18 - idle-state : if present, array of states that the mux controllers will have
19 when idle. The special state MUX_IDLE_AS_IS is the default and
22 States 0 through 3 correspond to signals A through D in the datasheet.
[all …]
|
| D | reg-mux.txt | 1 Generic register bitfield-based multiplexer controller bindings
7 - compatible : should be one of
8 "reg-mux" : if parent device of mux controller is not syscon device
9 "mmio-mux" : if parent device of mux controller is syscon device
10 - #mux-control-cells : <1>
11 - mux-reg-masks : an array of register offset and pre-shifted bitfield mask
13 * Standard mux-controller bindings as decribed in mux-controller.txt
16 - idle-states : if present, the state the muxes will have when idle. The
21 pair in the mux-reg-masks array.
28 compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c",
[all …]
|
| D | mux-controller.txt | 10 A mux controller provides a number of states to its consumers, and the state
11 space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
12 0-7 for an 8-way multiplexer, etc.
16 ---------
19 want to use with a property containing a 'mux-ctrl-list':
21 mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
22 single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
23 mux-ctrl-phandle : phandle to mux controller node
24 mux-ctrl-specifier : array of #mux-control-cells specifying the
27 Mux controller properties should be named "mux-controls". The exact meaning of
[all …]
|
| /Documentation/driver-api/thermal/ |
| D | intel_powerclamp.rst | 6 - Arjan van de Ven <arjan@linux.intel.com>
7 - Jacob Pan <jacob.jun.pan@linux.intel.com>
12 - Goals and Objectives
15 - Idle Injection
16 - Calibration
19 - Effectiveness and Limitations
20 - Power vs Performance
21 - Scalability
22 - Calibration
23 - Comparison with Alternative Techniques
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | lpit.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 Low Power Idle Table (LPIT)
7 To enumerate platform Low Power Idle states, Intel platforms are using
8 “Low Power Idle Table” (LPIT). More details about this table can be
15 On platforms supporting S0ix sleep states, there can be two types of
18 - CPU PKG C10 (Read via FFH interface)
19 - Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface)
|
| /Documentation/trace/ |
| D | coresight-cpu-debug.rst | 9 ------------
11 Coresight CPU debug module is defined in ARMv8-a architecture reference manual
13 debug module and it is mainly used for two modes: self-hosted debug and
16 explore debugging method which rely on self-hosted debug mode, this document
19 The debug module provides sample-based profiling extension, which can be used
21 every CPU has one dedicated debug module to be connected. Based on self-hosted
29 --------------
31 - During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
32 registers to decide if sample-based profiling is implemented or not. On some
36 - At the time this documentation was written, the debug driver mainly relies on
[all …]
|
| D | events-power.rst | 8 - Power state switch which reports events related to suspend (S-states),
9 cpuidle (C-states) and cpufreq (P-states)
10 - System clock related changes
11 - Power domains related changes and transitions
22 -----------------
24 A 'cpu' event class gathers the CPU-related events: cpuidle and
39 Note: the value of '-1' or '4294967295' for state means an exit from the current state,
41 enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
42 means that the system exits the previous idle state.
46 correctly draw the states diagrams and to calculate accurate statistics etc.
|
| /Documentation/devicetree/bindings/cpufreq/ |
| D | cpufreq-mediatek.txt | 5 - clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names.
6 - clock-names: Should contain the following:
7 "cpu" - The multiplexer for clock input of CPU cluster.
8 "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
11 Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
13 - operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
15 - proc-supply: Regulator for Vproc of CPU cluster.
18 - sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver
23 - #cooling-cells:
30 compatible = "operating-points-v2";
[all …]
|
| /Documentation/devicetree/bindings/mmc/ |
| D | ti-omap-hsmmc.txt | 10 --------------------
11 - compatible:
12 Should be "ti,omap2-hsmmc", for OMAP2 controllers
13 Should be "ti,omap3-hsmmc", for OMAP3 controllers
14 Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
15 Should be "ti,omap4-hsmmc", for OMAP4 controllers
16 Should be "ti,am33xx-hsmmc", for AM335x controllers
17 Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers.
20 ---------------------------------
22 - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1.
[all …]
|
| /Documentation/RCU/Design/Memory-Ordering/ |
| D | Tree-RCU-Memory-Ordering.html | 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
4 <head><title>A Tour Through TREE_RCU's Grace-Period Memory Ordering</title>
5 <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
13 grace-period memory ordering guarantee is provided.
28 <p>RCU grace periods provide extremely strong memory-ordering guarantees
29 for non-idle non-offline code.
32 period that are within RCU read-side critical sections.
35 of that grace period that are within RCU read-side critical sections.
37 <p>Note well that RCU-sched read-side critical sections include any region
40 an extremely small region of preemption-disabled code, one can think of
[all …]
|
| /Documentation/power/ |
| D | interface.rst | 14 Reading from it returns a list of supported sleep states, encoded as:
16 - 'freeze' (Suspend-to-Idle)
17 - 'standby' (Power-On Suspend)
18 - 'mem' (Suspend-to-RAM)
19 - 'disk' (Suspend-to-Disk)
21 Suspend-to-Idle is always supported. Suspend-to-Disk is always supported
24 for Suspend-to-RAM and Power-On Suspend depends on the capabilities of the
29 Documentation/admin-guide/pm/sleep-states.rst for a description of each of
30 those states.
32 /sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk).
[all …]
|
| /Documentation/RCU/ |
| D | stallwarn.txt | 5 options that can be used to fine-tune the detector's operation. Finally,
15 o A CPU looping in an RCU read-side critical section.
29 keep up with the boot-time console-message rate. For example,
30 a 115Kbaud serial console can be -way- too slow to keep up
31 with boot-time message rates, and will frequently result in
35 o Anything that prevents RCU's grace-period kthreads from running.
36 This can result in the "All QSes seen" console-log message.
39 result in the "rcu_.*kthread starved for" console-log message,
42 o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
43 happen to preempt a low-priority task in the middle of an RCU
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-system-cpu | 2 Date: pre-git history
3 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
18 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
37 See Documentation/admin-guide/cputopology.rst for more information.
43 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
58 Contact: Linux memory management mailing list <linux-mm@kvack.org>
67 /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
77 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
93 core_siblings_list: human-readable list of the logical CPU
103 thread_siblings_list: human-readable list of cpu#'s hardware
[all …]
|
| /Documentation/admin-guide/ |
| D | cpu-load.rst | 10 Linux 2.6.18.3-exp (linmac) 02/20/2007
12 avg-cpu: %user %nice %system %iowait %steal %idle
19 kernel, and was overall 81.63% of the time idle.
29 switched between various states multiple times between two timer
34 -------
40 |--------------------------------------|
48 system is executing the idle handler), but in reality the load is
55 /* gcc -o hog smallhog.c */
72 while (!stop && --niters);
88 for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX);
[all …]
|
123