arch/arm/cluster-pm-race-avoidance.rst

2 Cluster-wide Power-up/power-down race avoidance algorithm
6 cluster setup and teardown operations and to manage hardware coherency
29 cluster-level operations are only performed when it is truly safe to do
34 are not immediately enabled when a cluster powers up.  Since enabling or
38 power-down and power-up at the cluster level.
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
81 	The CPU or cluster has committed to moving to the DOWN
89 Each cluster is also assigned a state, but it is necessary to split the
90 state value into two parts (the "cluster" state and "inbound" state) and
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
97 and a `CLUSTER_` or `INBOUND_` prefix for the cluster states.
118 	 cluster setup and
161 	cluster is set up and coherent.  If the cluster is not ready,
163 	cluster has been set up.
168 		The CPU's parent cluster must be in CLUSTER_UP.
170 		Transition of the parent cluster to CLUSTER_UP.
172 	Refer to the "Cluster state" section for a description of the
213 Cluster state
216 A cluster is a group of connected CPUs with some common resources.
217 Because a cluster contains multiple CPUs, it can be doing multiple
219 CPU can start up while another CPU is tearing the cluster down.
221 In this discussion, the "outbound side" is the view of the cluster state
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
228 reason, the cluster state is split into two parts:
230 	"cluster" state: The global state of the cluster; or the state
237 	"inbound" state: The state of the cluster on the inbound side.
244 	states for the cluster as a whole::
264 	only involve changes to the "cluster" state.
269 	outbound CPU has put the cluster into the CLUSTER_DOWN state).
272 	which exact CPUs within the cluster play these roles.  This must
278 	cluster can actually be powered down.
284 	COMING_UP in the basic model).  The second path avoids cluster
296 		<cluster state>/<inbound state> (<transitioner>)
317 	In this state, an inbound CPU sets up the cluster, including
318 	enabling of hardware coherency at the cluster level and any
322 	The purpose of this state is to do sufficient cluster-level
323 	setup to enable other CPUs in the cluster to enter coherency
329 		cluster-level setup and hardware coherency complete
336 	Cluster-level setup is complete and hardware coherency is
337 	enabled for the cluster.  Other CPUs in the cluster can safely
341 	CLUSTER_UP/INBOUND_NOT_COMING_UP.  All other CPUs on the cluster
354 	Cluster-level setup is complete and hardware coherency is
355 	enabled for the cluster.  Other CPUs in the cluster can safely
358 	The cluster will remain in this state until a policy decision is
359 	made to power the cluster down.
366 		policy decision to power down the cluster
371 	An outbound CPU is tearing the cluster down.  The selected CPU
372 	must wait in this state until all CPUs in the cluster are in the
375 	When all CPUs are in the CPU_DOWN state, the cluster can be torn
377 	cluster-level coherency.
380 	should check the inbound cluster state for asynchronous
389 			cluster torn down and ready to power off
407 	The cluster is (or was) being torn down, but another CPU has
408 	come online in the meantime and is trying to set up the cluster
413 		a) back out of teardown, restoring the cluster to the
416 		b) finish tearing the cluster down and put the cluster
418 		   set up the cluster again from there.
422 	the cluster is not really going to be powered down.
429 				cluster-level setup and hardware
437 			cluster torn down and ready to power off
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
458 When shutting down the cluster, all the CPUs involved are initially
468 attempts to play the first man role and do the cluster-level
472 Cluster-level initialisation may involve actions such as configuring
503 	the case of an aborted cluster power-down).
507 	is needed for safe transitions at the cluster level.
509 	A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
520 	extended by replicating the cluster-level states for the
522 	rules for the intermediate (non-outermost) cluster levels.