| b0408e87 | 05-Jan-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
PSCI: Optimize call paths if all participants are cache-coherent
The current PSCI implementation can apply certain optimizations upon the assumption that all PSCI participants are cache-coherent.
PSCI: Optimize call paths if all participants are cache-coherent
The current PSCI implementation can apply certain optimizations upon the assumption that all PSCI participants are cache-coherent.
- Skip performing cache maintenance during power-up.
- Skip performing cache maintenance during power-down:
At present, on the power-down path, CPU driver disables caches and MMU, and performs cache maintenance in preparation for powering down the CPU. This means that PSCI must perform additional cache maintenance on the extant stack for correct functioning.
If all participating CPUs are cache-coherent, CPU driver would neither disable MMU nor perform cache maintenance. The CPU being powered down, therefore, remain cache-coherent throughout all PSCI call paths. This in turn means that PSCI cache maintenance operations are not required during power down.
- Choose spin locks instead of bakery locks:
The current PSCI implementation must synchronize both cache-coherent and non-cache-coherent participants. Mutual exclusion primitives are not guaranteed to function on non-coherent memory. For this reason, the current PSCI implementation had to resort to bakery locks.
If all participants are cache-coherent, the implementation can enable MMU and data caches early, and substitute bakery locks for spin locks. Spin locks make use of architectural mutual exclusion primitives, and are lighter and faster.
The optimizations are applied when HW_ASSISTED_COHERENCY build option is enabled, as it's expected that all PSCI participants are cache-coherent in those systems.
Change-Id: Iac51c3ed318ea7e2120f6b6a46fd2db2eae46ede Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| e5bbd16a | 31-Jan-2017 |
dp-arm <dimitris.papastamos@arm.com> |
PSCI: Do stat accounting for retention/standby states
Perform stat accounting for retention/standby states also when requested at multiple power levels.
Change-Id: I2c495ea7cdff8619bde323fb641cd844
PSCI: Do stat accounting for retention/standby states
Perform stat accounting for retention/standby states also when requested at multiple power levels.
Change-Id: I2c495ea7cdff8619bde323fb641cd84408eb5762 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| 04c1db1e | 31-Jan-2017 |
dp-arm <dimitris.papastamos@arm.com> |
PSCI: Decouple PSCI stat residency calculation from PMF
This patch introduces the following three platform interfaces:
* void plat_psci_stat_accounting_start(const psci_power_state_t *state_info)
PSCI: Decouple PSCI stat residency calculation from PMF
This patch introduces the following three platform interfaces:
* void plat_psci_stat_accounting_start(const psci_power_state_t *state_info)
This is an optional hook that platforms can implement in order to perform accounting before entering a low power state. This typically involves capturing a timestamp.
* void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info)
This is an optional hook that platforms can implement in order to perform accounting after exiting from a low power state. This typically involves capturing a timestamp.
* u_register_t plat_psci_stat_get_residency(unsigned int lvl, const psci_power_state_t *state_info, unsigned int last_cpu_index)
This is an optional hook that platforms can implement in order to calculate the PSCI stat residency.
If any of these interfaces are overridden by the platform, it is recommended that all of them are.
By default `ENABLE_PSCI_STAT` is disabled. If `ENABLE_PSCI_STAT` is set but `ENABLE_PMF` is not set then an alternative PSCI stat collection backend must be provided. If both are set, then default weak definitions of these functions are provided, using PMF to calculate the residency.
NOTE: Previously, platforms did not have to explicitly set `ENABLE_PMF` since this was automatically done by the top-level Makefile.
Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| 5dd9dbb5 | 18-Nov-2016 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Add provision to extend CPU operations at more levels
Various CPU drivers in ARM Trusted Firmware register functions to handle power-down operations. At present, separate functions are registered to
Add provision to extend CPU operations at more levels
Various CPU drivers in ARM Trusted Firmware register functions to handle power-down operations. At present, separate functions are registered to power down individual cores and clusters.
This scheme operates on the basis of core and cluster, and doesn't cater for extending the hierarchy for power-down operations. For example, future CPUs might support multiple threads which might need powering down individually.
This patch therefore reworks the CPU operations framework to allow for registering power down handlers on specific level basis. Henceforth:
- Generic code invokes CPU power down operations by the level required.
- CPU drivers explicitly mention CPU_NO_RESET_FUNC when the CPU has no reset function.
- CPU drivers register power down handlers as a list: a mandatory handler for level 0, and optional handlers for higher levels.
All existing CPU drivers are adapted to the new CPU operations framework without needing any functional changes within.
Also update firmware design guide.
Change-Id: I1826842d37a9e60a9e85fdcee7b4b8f6bc1ad043 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|