Lines Matching refs:CPU
5 This file documents the algorithm which is used to coordinate CPU and
48 Each cluster and CPU is assigned a state, as follows:
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.
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,
100 CPU state
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:
119 CPU setup complete policy decision
127 policy decision CPU teardown complete
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
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
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
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).
310 from a policy decision on another CPU;
317 In this state, an inbound CPU sets up the cluster, including
371 An outbound CPU is tearing the cluster down. The selected CPU
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
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
467 events, a dynamic mechanism is needed to make sure that only one CPU
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
497 involve CPU-specific setup code, but in the current
506 functions due to the extra inter-CPU coordination which
518 support CPU topologies involving more than two levels (i.e.,