Lines Matching +full:cpu +full:- +full:idle +full:- +full:states
2 Cluster-wide Power-up/power-down race avoidance algorithm
5 This file documents the algorithm which is used to coordinate CPU and
16 ---------
19 ability to turn off individual CPUs when the system is idle, reducing
29 cluster-level operations are only performed when it is truly safe to do
35 disabling those mechanisms may itself be a non-atomic operation (such as
38 power-down and power-up at the cluster level.
46 -----------
48 Each cluster and CPU is assigned a state, as follows:
50 - DOWN
51 - COMING_UP
52 - UP
53 - GOING_DOWN
57 +---------> UP ----------+
63 +--------- DOWN <--------+
67 The CPU or cluster is not coherent, and is either powered off or
71 The CPU or cluster has committed to moving to the UP state.
76 The CPU or cluster is active and coherent at the hardware
77 level. A CPU in this state is not necessarily being used
81 The CPU or cluster has committed to moving to the DOWN
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
92 CPUs in the cluster simultaneously modifying the state. The cluster-
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.
100 CPU state
101 ---------
103 In this algorithm, each individual core in a multi-core processor is
104 referred to as a "CPU". CPUs are assumed to be single-threaded:
105 therefore, a CPU can only be doing one thing at a single point in time.
109 The algorithm defines the following states for each CPU in the system:
111 - CPU_DOWN
112 - CPU_COMING_UP
113 - CPU_UP
114 - CPU_GOING_DOWN
119 CPU setup complete policy decision
120 +-----------> CPU_UP ------------+
126 +----------- CPU_DOWN <----------+
127 policy decision CPU teardown complete
131 The definitions of the four states correspond closely to the states of
134 Transitions between states occur as follows.
136 A trigger event (spontaneous) means that the CPU can transition to the
142 A CPU reaches the CPU_DOWN state when it is ready for
143 power-down. On reaching this state, the CPU will typically
153 a) an explicit hardware power-up operation, resulting
154 from a policy decision on another CPU;
160 A CPU cannot start participating in hardware coherency until the
162 then the CPU will wait in the CPU_COMING_UP state until the
168 The CPU's parent cluster must be in CLUSTER_UP.
177 When a CPU reaches the CPU_UP state, it is safe for the CPU to
180 This is done by jumping to the kernel's CPU resume code.
184 CPU is coherent yet, but it does mean that it is safe to resume
189 The CPU remains in this state until an explicit policy decision
190 is made to shut down or suspend the CPU.
201 While in this state, the CPU exits coherency, including any
208 local CPU teardown complete
214 -------------
219 CPU can start up while another CPU is tearing the cluster down.
222 as seen by a CPU tearing the cluster down. The "inbound side" is the
223 view of the cluster state as seen by a CPU setting the CPU up.
226 that a CPU which is setting up the cluster can advertise its state
227 independently of the CPU which is tearing down the cluster. For this
233 - CLUSTER_DOWN
234 - CLUSTER_UP
235 - CLUSTER_GOING_DOWN
239 - INBOUND_NOT_COMING_UP
240 - INBOUND_COMING_UP
243 The different pairings of these states results in six possible
244 states for the cluster as a whole::
247 +==========> INBOUND_NOT_COMING_UP -------------+
250 CLUSTER_UP <----+ |
257 INBOUND_COMING_UP <----+ |
260 +=========== CLUSTER_DOWN <------------+
263 Transitions -----> can only be made by the outbound CPU, and
266 Transitions ===##> can only be made by the inbound CPU, and only
269 outbound CPU has put the cluster into the CLUSTER_DOWN state).
309 a) an explicit hardware power-up operation, resulting
310 from a policy decision on another CPU;
317 In this state, an inbound CPU sets up the cluster, including
322 The purpose of this state is to do sufficient cluster-level
329 cluster-level setup and hardware coherency complete
336 Cluster-level setup is complete and hardware coherency is
342 should consider treat these two states as equivalent.
354 Cluster-level setup is complete and hardware coherency is
371 An outbound CPU is tearing the cluster down. The selected CPU
377 cluster-level coherency.
385 Next states:
398 a) an explicit hardware power-up operation,
400 CPU;
407 The cluster is (or was) being torn down, but another CPU has
411 If the outbound CPU observes this state, it has two choices:
417 in the CLUSTER_DOWN state; the inbound CPU will
425 Next states:
429 cluster-level setup and hardware
444 --------------------------------
446 The CPU which performs cluster tear-down operations on the outbound side
449 The CPU which performs cluster setup on the inbound side is commonly
461 non-coherent.
466 Because CPUs may power up asynchronously in response to external wake-up
467 events, a dynamic mechanism is needed to make sure that only one CPU
468 attempts to play the first man role and do the cluster-level
472 Cluster-level initialisation may involve actions such as configuring
481 ------------------------
485 The current ARM-based implementation is split between
486 arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
489 __mcpm_cpu_going_down() signals the transition of a CPU to the
492 __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
495 A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
496 low-level power-up code in mcpm_head.S. This could
497 involve CPU-specific setup code, but in the current
503 the case of an aborted cluster power-down).
506 functions due to the extra inter-CPU coordination which
510 the low-level power-up code in mcpm_head.S. This
511 typically involves platform-specific setup code,
512 provided by the platform-specific power_up_setup
518 support CPU topologies involving more than two levels (i.e.,
520 extended by replicating the cluster-level states for the
522 rules for the intermediate (non-outermost) cluster levels.
526 --------
531 Copyright (C) 2012-2013 Linaro Limited