Searched full:states (Results 1 – 25 of 255) sorted by relevance
1234567891011
| /Documentation/admin-guide/pm/ |
| D | intel_idle.rst | 28 processor's functional blocks into low-power states. That instruction takes two
42 .. _intel-idle-enumeration-of-states:
44 Enumeration of Idle States
50 as C-states (in the ACPI terminology) or idle states. The list of meaningful
51 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
55 In order to create a list of available idle states required by the ``CPUIdle``
56 subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`),
57 ``intel_idle`` can use two sources of information: static tables of idle states
68 states, ``intel_idle`` first looks for a ``_CST`` object under one of the ACPI
71 ``CPUIdle`` subsystem expects that the list of idle states supplied by the
[all …]
|
| D | strategies.rst | 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
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
32 ``inactive`` (idle). If they are active, they have to be in power states
34 are inactive, ideally, they should be in low-power states in which they may not
43 for the same system in a sleep state. However, transitions from sleep states
47 sleep states than when they are runtime idle most of the time.
|
| D | intel_pstate.rst | 27 information about that). For this reason, the representation of P-states used
32 ``intel_pstate`` maps its internal representation of P-states to frequencies too
69 hardware-managed P-states (HWP) support. If it works in this mode, the
89 depends on whether or not the hardware-managed P-states (HWP) feature has been
106 select P-states by itself, but still it can give hints to the processor's
130 Also, in this configuration the range of P-states available to the processor's
182 registers of the CPU. It generally selects P-states proportional to the
199 hardware-managed P-states (HWP) support. It is always used if the
223 the entire range of available P-states is exposed by ``intel_pstate`` to the
232 Turbo P-states Support
[all …]
|
| D | cpuidle.rst | 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
28 the idle states of processors for this purpose.
56 except for one have been put into idle states at the "core level" and the
75 larger unit are in idle states already).
90 Tasks can be in various states. In particular, they are *runnable* if there are
104 code may cause the processor to be put into one of its idle states, if they are
106 idle states, or there is not enough time to spend in an idle state before the
108 available idle states from being used, the CPU will simply execute more or less
[all …]
|
| D | suspend-flows.rst | 14 :doc:`sleep states <sleep-states>`. Hibernation requires more than one
15 transition to occur for this purpose, but the other sleep states, commonly
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
19 For those sleep states, the transition from the working state of the system into
26 different sleep states of the system are quite similar, but there are some
29 :ref:`standby <standby>` sleep states.
31 The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
36 states are mostly identical, so they both together will be referred to as
37 *platform-dependent suspend* states in what follows.
187 when all CPUs in them are in sufficiently deep idle states and all I/O
[all …]
|
| D | sleep-states.rst | 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
34 I/O devices into low-power states (possibly lower-power than available in the
36 states while the system is suspended.
58 I/O devices into low-power states, which is done for :ref:`suspend-to-idle
89 suspended and put into low-power states. In many cases, all peripheral buses
163 This file contains a list of strings representing sleep states supported
[all …]
|
| /Documentation/devicetree/bindings/arm/ |
| D | idle-states.yaml | 4 $id: http://devicetree.org/schemas/arm/idle-states.yaml#
7 title: ARM idle states binding description
18 where cores can be put in different low-power states (ranging from simple wfi
19 to power gating) according to OS PM policies. The CPU states representing the
20 range of dynamic idle states that a processor can enter at run-time, can be
22 enter/exit specific idle states on a given processor.
25 power states an ARM CPU can be put into are identified by the following list:
33 The power states described in the SBSA document define the basic CPU states on
35 PM implementation to put the processor in different idle states (which include
36 states listed above; "off" state is not an idle state since it does not have
[all …]
|
| D | psci.yaml | 103 [1] Kernel documentation - ARM idle states bindings
104 Documentation/devicetree/bindings/arm/idle-states.yaml
115 own specific power states and can be better represented hierarchically.
117 For these cases, the definitions of the idle states for the CPUs and the
118 CPU topology, must conform to the binding in [3]. The idle states
192 // Case 4: CPUs and CPU idle states described using the hierarchical model.
216 idle-states {
227 domain-idle-states {
253 domain-idle-states = <&CPU_PWRDN>;
259 domain-idle-states = <&CPU_PWRDN>;
[all …]
|
| D | cpu-capacity.txt | 98 idle-states {
127 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
138 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
149 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
160 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
171 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
182 cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
|
| /Documentation/admin-guide/blockdev/drbd/ |
| D | figures.rst | 20 .. kernel-figure:: conn-states-8.dot
21 :alt: conn-states-8.dot
24 .. kernel-figure:: disk-states-8.dot
25 :alt: disk-states-8.dot
28 .. kernel-figure:: node-states-8.dot
29 :alt: node-states-8.dot
|
| /Documentation/devicetree/bindings/powerpc/opal/ |
| D | power-mgt.txt | 5 idle states. The description of these idle states is exposed via the
14 - flags: indicating some aspects of this idle states such as the
16 idle states and so on. The flag bits are as follows:
27 The following properties provide details about the idle states. These
32 If idle-states are defined, then the properties
38 Array of strings containing the names of the idle states.
42 flags associated with the the aforementioned idle-states. The
62 exit-latencies (in ns) for the idle states in
67 target-residency (in ns) for the idle states in
75 PSSCR for each of the idle states in ibm,cpu-idle-state-names.
[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].
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
59 the idle-states device node.
75 idle-states {
84 [1]. Documentation/devicetree/bindings/arm/idle-states.yaml
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-power | 15 from sleep states, such as the memory sleep state (suspend to
33 be enabled to wake up the system from sleep states.
87 the system from sleep states, this attribute is not present.
89 states, this attribute is empty.
99 system from sleep states, this attribute is not present. If
101 states, this attribute is empty.
111 is not capable to wake up the system from sleep states, this
113 up the system from sleep states, this attribute is empty.
123 from sleep states, this attribute is not present. If the
124 device is not enabled to wake up the system from sleep states,
[all …]
|
| D | sysfs-class-fpga-manager | 18 This is a superset of FPGA states and fpga manager driver
19 states. The fpga manager driver is walking through these steps
21 though some steps may get skipped. Valid FPGA states will vary
|
| /Documentation/devicetree/bindings/power/ |
| D | power-domain.yaml | 30 domain-idle-states:
33 Phandles of idle states that defines the available states for the
37 Note that, the domain-idle-state property reflects the idle states of this
38 PM domain and not the idle states of the devices or sub-domains in the PM
39 domain. Devices and sub-domains have their own idle states independent of
40 the parent domain's idle states. In the absence of this property, the
108 domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
116 domain-idle-states = <&DOMAIN_PWR_DN>;
119 domain-idle-states {
|
| D | domain-idle-state.yaml | 7 title: PM Domain Idle States binding description
18 const: domain-idle-states
58 domain-idle-states {
|
| /Documentation/devicetree/bindings/regulator/ |
| D | gpio-regulator.yaml | 35 voltage/current listed in "states".
39 gpios-states:
55 states:
58 no states in the "states" array, use a fixed regulator instead.
92 - states
109 states = <1800000 0x3>,
|
| D | rohm,bd71828-regulator.yaml | 83 # Supported default DVS states:
91 #(*) LPSR and SUSPEND states use same voltage but both states have own
96 #(**) All states use same voltage but have own enable / disable
|
| /Documentation/driver-api/pm/ |
| D | cpuidle.rst | 25 However, there may be multiple different idle states that can be used in such a
35 units: *governors* responsible for selecting idle states to ask the processor
85 struct cpuidle_state objects representing idle states that the
117 The list of idle states to take into consideration is represented by the
118 :c:member:`states` array of struct cpuidle_state objects held by the
149 account when selecting idle states. In order to obtain the current effective
164 First of all, a ``CPUIdle`` driver has to populate the :c:member:`states` array
167 idle states that the processor hardware can be asked to enter shared by all of
170 The entries in the :c:member:`states` array are expected to be sorted by the
214 :c:member:`states` array representing the idle state to ask the processor to
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | pinctrl-bindings.txt | 17 states. The number and names of those states is defined by the client device's
22 configuration used by those states.
31 they require certain specific named states for dynamic pin configuration.
41 Each client device's own binding determines the set of states that must be
61 the binding for that IP block requires certain pin states to
70 pinctrl-names: The list of names to assign states. List entry 0 defines the
76 /* For a client device requiring named states */
|
| /Documentation/devicetree/bindings/thermal/ |
| D | thermal-cooling-devices.yaml | 30 scaling (DVFS), and uses lower frequencies as cooling states.
34 Any cooling device has a range of cooling states (i.e. different levels of
36 which the device is. For example, a fan's cooling states correspond to the
37 different fan speeds possible. Cooling states are referred to by single
39 precise set of cooling states associated with a device should be defined in
69 cpu-idle-states = <&LITTLE_CPU_SLEEP_0
|
| /Documentation/arm/ |
| D | cluster-pm-race-avoidance.rst | 86 Each CPU has one of these states assigned to it at any point in time.
87 The CPU states are described in the "CPU state" section, below.
91 to introduce additional states in order to avoid races between different
93 level states are described in the "Cluster state" section.
95 To help distinguish the CPU states from cluster states in this
96 discussion, the state names are given a `CPU_` prefix for the CPU states,
97 and a `CLUSTER_` or `INBOUND_` prefix for the cluster states.
109 The algorithm defines the following states for each CPU in the system:
131 The definitions of the four states correspond closely to the states of
134 Transitions between states occur as follows.
[all …]
|
| /Documentation/filesystems/caching/ |
| D | object.rst | 18 (*) The set of states.
99 states.
102 wakes up in that state. There are four logical sets of states:
104 (1) Preparation: states that wait for the parent objects to become ready. The
108 (2) Initialisation: states that perform lookups in the cache and validate
111 (3) Normal running: states that allow netfs operations on objects to proceed
114 (4) Termination: states that detach objects from their netfs cookies, that
119 In most cases, transitioning between states is in response to signalled events.
130 The work to be done by the various states was given CPU time by the threads of
154 The Set of States
[all …]
|
| /Documentation/trace/ |
| D | events-power.rst | 8 - Power state switch which reports events related to suspend (S-states),
9 cpuidle (C-states) and cpufreq (P-states)
46 correctly draw the states diagrams and to calculate accurate statistics etc.
|
| /Documentation/firmware-guide/acpi/ |
| D | lpit.rst | 7 To enumerate platform Low Power Idle states, Intel platforms are using
15 On platforms supporting S0ix sleep states, there can be two types of
|
1234567891011