Lines Matching refs:to
25 Juno supports CPU, cluster and system power down states, corresponding to power
34 SCP_BL2=<path/to/scp-fw.bin> \
35 BL33=<path/to/test-fw.bin> \
49 brings them and the lead CPU to a common synchronization point. The lead CPU
54 test to complete before proceeding to the next non-lead CPU. The lead CPU then
57 In the results below, CPUs 0-3 refer to CPUs in the little cluster (A53) and
58 CPUs 4-5 refer to CPUs in the big cluster (A57). In all cases CPU 4 is the lead
61 ``PSCI_ENTRY`` refers to the time taken from entering the TF PSCI implementation
62 to the point the hardware enters the low power state (WFI). Referring to the TF
63 runtime instrumentation points, this corresponds to:
66 ``PSCI_EXIT`` refers to the time taken from the point the hardware exits the low
67 power state to exiting the TF PSCI implementation. This corresponds to:
70 ``CFLUSH_OVERHEAD`` refers to the part of ``PSCI_ENTRY`` taken to flush the
71 caches. This corresponds to: ``(RT_INSTR_EXIT_CFLUSH - RT_INSTR_ENTER_CFLUSH)``.
85 ``CPU_SUSPEND`` to deepest power level on all CPUs in parallel
105 observed due to TF PSCI lock contention. In the worst case, CPU 3 has to wait
106 for the 3 other CPUs in the cluster (0-2) to complete ``PSCI_ENTRY`` and release
110 last CPUs in their respective clusters to power down, therefore both the L1 and
114 because the L2 cache size for the big cluster is lot larger (2MB) compared to
117 ``CPU_SUSPEND`` to power level 0 on all CPUs in parallel
137 variance in ``PSCI_ENTRY`` times across CPUs is due to lock contention in Juno
138 platform code. The platform lock is used to mediate access to a single SCP
140 AP CPU to enter WFI before making the channel available to other CPUs, which
144 possible to make the ``PSCI_ENTRY`` times smaller and consistent.
152 ``CPU_SUSPEND`` to deepest power level on all CPUs in sequence
173 test. The ``CPU_SUSPEND`` call powers down to the cluster level, requiring a
178 to the little cluster (1MB).
181 CPU 4 continues to run while CPU 5 is suspended. Hence CPU 5 only powers down to
184 ``CPU_SUSPEND`` to power level 0 on all CPUs in sequence
204 only necessary to flush the cache to power level 0 (L1). This is the best case
208 for the CPUs in little cluster due to greater CPU performance.
211 cluster remains powered on throughout the test and there is less code to execute
212 on power on (for example, no need to enter CCI coherency)
214 ``CPU_OFF`` on all non-lead CPUs in sequence then ``CPU_SUSPEND`` on lead CPU to deepest power level
221 2. Program wake up timer and suspend the lead CPU to the deepest power level.
223 3. Call ``CPU_ON`` on non-lead CPU to get the timestamps from each CPU.
243 powers down to the cluster level, requiring a flush of both L1 and L2 caches.
246 lead CPU 4 is running and CPU 5 only powers down to level 0, which only requires
251 to the little cluster (1MB).
254 for CPUs in the little cluster due to greater CPU performance. These times
256 because there is more code to execute in the "on finisher" compared to the
281 The times for the big CPUs are less than the little CPUs due to greater CPU
284 We suspect the time for lead CPU 4 is shorter than CPU 5 due to subtle cache