Lines Matching refs:CPU
4 This file documents the algorithm which is used to coordinate CPU and
47 Each cluster and CPU is assigned a state, as follows:
63 DOWN: The CPU or cluster is not coherent, and is either powered off or
66 COMING_UP: The CPU or cluster has committed to moving to the UP state.
70 UP: The CPU or cluster is active and coherent at the hardware
71 level. A CPU in this state is not necessarily being used
74 GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
79 Each CPU has one of these states assigned to it at any point in time.
80 The CPU states are described in the "CPU state" section, below.
88 To help distinguish the CPU states from cluster states in this
89 discussion, the state names are given a CPU_ prefix for the CPU states,
93 CPU state
97 referred to as a "CPU". CPUs are assumed to be single-threaded:
98 therefore, a CPU can only be doing one thing at a single point in time.
102 The algorithm defines the following states for each CPU in the system:
110 CPU setup complete policy decision
118 policy decision CPU teardown complete
127 A trigger event (spontaneous) means that the CPU can transition to the
134 A CPU reaches the CPU_DOWN state when it is ready for
135 power-down. On reaching this state, the CPU will typically
145 from a policy decision on another CPU;
152 A CPU cannot start participating in hardware coherency until the
154 then the CPU will wait in the CPU_COMING_UP state until the
158 Conditions: The CPU's parent cluster must be in CLUSTER_UP.
166 When a CPU reaches the CPU_UP state, it is safe for the CPU to
169 This is done by jumping to the kernel's CPU resume code.
173 CPU is coherent yet, but it does mean that it is safe to resume
178 The CPU remains in this state until an explicit policy decision
179 is made to shut down or suspend the CPU.
188 While in this state, the CPU exits coherency, including any
193 Conditions: local CPU teardown complete
203 CPU can start up while another CPU is tearing the cluster down.
206 as seen by a CPU tearing the cluster down. The "inbound side" is the
207 view of the cluster state as seen by a CPU setting the CPU up.
210 that a CPU which is setting up the cluster can advertise its state
211 independently of the CPU which is tearing down the cluster. For this
247 Transitions -----> can only be made by the outbound CPU, and
250 Transitions ===##> can only be made by the inbound CPU, and only
253 outbound CPU has put the cluster into the CLUSTER_DOWN state).
293 from a policy decision on another CPU;
300 In this state, an inbound CPU sets up the cluster, including
345 An outbound CPU is tearing the cluster down. The selected CPU
371 CPU;
378 The cluster is (or was) being torn down, but another CPU has
382 If the outbound CPU observes this state, it has two choices:
388 in the CLUSTER_DOWN state; the inbound CPU will
411 The CPU which performs cluster tear-down operations on the outbound side
414 The CPU which performs cluster setup on the inbound side is commonly
432 events, a dynamic mechanism is needed to make sure that only one CPU
451 arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
454 __mcpm_cpu_going_down() signals the transition of a CPU to the
457 __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
460 A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
462 involve CPU-specific setup code, but in the current
471 functions due to the extra inter-CPU coordination which
483 support CPU topologies involving more than two levels (i.e.,