Searched +full:idle +full:- +full:states (Results 1 – 25 of 73) sorted by relevance
123
| /Documentation/admin-guide/pm/ |
| D | intel_idle.rst | 1 .. SPDX-License-Identifier: GPL-2.0
5 ``intel_idle`` CPU Idle Time Management Driver
17 :doc:`CPU idle time management subsystem <cpuidle>` in the Linux kernel
18 (``CPUIdle``). It is the default CPU idle time management driver for the
27 logical CPU executing it is idle and so it may be possible to put some of the
28 processor's functional blocks into low-power states. That instruction takes two
38 only way to pass early-configuration-time parameters to it is via the kernel
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
[all …]
|
| 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 | suspend-flows.rst | 1 .. SPDX-License-Identifier: GPL-2.0
12 At least one global system-wide transition needs to be carried out for the
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
27 significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
28 and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
29 :ref:`standby <standby>` sleep states.
[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/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/ |
| D | idle-states.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/arm/idle-states.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: ARM idle states binding description
10 - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
14 1 - Introduction
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
[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
40 - description:
44 - description:
46 const: arm,psci-0.2
[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 …]
|
| /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/driver-api/pm/ |
| D | cpuidle.rst | 1 .. SPDX-License-Identifier: GPL-2.0
5 CPU Idle Time Management
13 CPU Idle Time Management Subsystem
18 cores) is idle after an interrupt or equivalent wakeup event, which means that
19 there are no tasks to run on it except for the special "idle" task associated
21 belongs to. That can be done by making the idle logical CPU stop fetching
23 depended on by it into an idle state in which they will draw less power.
25 However, there may be multiple different idle states that can be used in such a
28 particular idle state. That is the role of the CPU idle time management
35 units: *governors* responsible for selecting idle states to ask the processor
[all …]
|
| /Documentation/devicetree/bindings/power/ |
| D | power-domain.yaml | 1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/power/power-domain.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Rafael J. Wysocki <rjw@rjwysocki.net>
11 - Kevin Hilman <khilman@kernel.org>
12 - Ulf Hansson <ulf.hansson@linaro.org>
24 \#power-domain-cells property in the PM domain provider node.
28 pattern: "^(power-controller|power-domain)([@-].*)?$"
30 domain-idle-states:
[all …]
|
| D | domain-idle-state.yaml | 1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/power/domain-idle-state.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: PM Domain Idle States binding description
10 - Ulf Hansson <ulf.hansson@linaro.org>
13 A domain idle state node represents the state parameters that will be used to
18 const: domain-idle-states
21 "^(cpu|cluster|domain)-":
24 Each state node represents a domain idle state description.
[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 …]
|
| /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/devicetree/bindings/thermal/ |
| D | thermal-idle.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
4 ---
5 $id: http://devicetree.org/schemas/thermal/thermal-idle.yaml#
6 $schema: http://devicetree.org/meta-schemas/core.yaml#
8 title: Thermal idle cooling device binding
11 - Daniel Lezcano <daniel.lezcano@linaro.org>
14 The thermal idle cooling device allows the system to passively
15 mitigate the temperature on the device by injecting idle cycles,
18 This binding describes the thermal idle node.
22 const: thermal-idle
[all …]
|
| /Documentation/devicetree/bindings/regulator/ |
| D | rohm,bd71828-regulator.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
3 ---
4 $id: http://devicetree.org/schemas/regulator/rohm,bd71828-regulator.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
14 see Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml.
16 The regulator controller is represented as a sub-node of the PMIC node
25 "^LDO[1-7]$":
32 regulator-name:
33 pattern: "^ldo[1-7]$"
[all …]
|
| /Documentation/trace/coresight/ |
| 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 …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | pinctrl-bindings.txt | 4 such as pull-up/down, tri-state, drive-strength etc are designated as pin
15 need to reconfigure pins at run-time, for example to tri-state pins when the
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
47 pinctrl-0: List of phandles, each pointing at a pin configuration
61 the binding for that IP block requires certain pin states to
65 pinctrl-1: List of phandles, each pointing at a pin configuration
68 pinctrl-n: List of phandles, each pointing at a pin configuration
[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)
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:
25 Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
[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 …]
|
123