Lines Matching +full:side +full:- +full:by +full:- +full:side
2 Cluster-wide Power-up/power-down race avoidance algorithm
16 ---------
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 -----------
50 - DOWN
51 - COMING_UP
52 - UP
53 - GOING_DOWN
57 +---------> UP ----------+
63 +--------- DOWN <--------+
78 actively by the kernel.
92 CPUs in the cluster simultaneously modifying the state. The cluster-
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:
111 - CPU_DOWN
112 - CPU_COMING_UP
113 - CPU_UP
114 - CPU_GOING_DOWN
120 +-----------> CPU_UP ------------+
126 +----------- CPU_DOWN <----------+
143 power-down. On reaching this state, the CPU will typically
153 a) an explicit hardware power-up operation, resulting
180 This is done by jumping to the kernel's CPU resume code.
214 -------------
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.
231 on the outbound side:
233 - CLUSTER_DOWN
234 - CLUSTER_UP
235 - CLUSTER_GOING_DOWN
237 "inbound" state: The state of the cluster on the inbound side.
239 - INBOUND_NOT_COMING_UP
240 - INBOUND_COMING_UP
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
268 further transition possible on the outbound side (i.e., the
273 be decided in advance by some other means. Refer to the section
280 The parallelism of the inbound and outbound CPUs is observed by
298 where the <transitioner> is the side on which the transition
299 can occur; either the inbound or the outbound side.
309 a) an explicit hardware power-up operation, resulting
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
354 Cluster-level setup is complete and hardware coherency is
376 down, for example by cleaning data caches and exiting
377 cluster-level coherency.
398 a) an explicit hardware power-up operation,
420 Choice (a) permits the removal of some latency by avoiding
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
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
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
520 extended by replicating the cluster-level states for the
522 rules for the intermediate (non-outermost) cluster levels.
526 --------
528 Originally created and documented by Dave Martin for Linaro Limited, in
531 Copyright (C) 2012-2013 Linaro Limited